Great! Just one thing - does the fact big_values
is limited to 8192 now mean a loss of quality?
>Imposing a maximum value of 8191 is a completely unneeded restriction
which results in a (very tiny) loss of quality.
I don't get this, since apparantly, it is a needed
restriction. Or is it
> X-Authentication-Warning: geek.rcc.se: majordom set sender to
>[EMAIL PROTECTED] using -f
> From: "Youri Pepplinkhuizen" <[EMAIL PROTECTED]>
> Date: Tue, 3 Oct 2000 09:22:08 +0200
> Content-Type: multipart/alternative;
> boundary="=_NextPart_000_0022_01C02D1B.673EA6E0"
> X-Priority: 3
Hmmm, nah I don't think it should. If even the ISO source uses 8206, why
change it when the Nitrane bug has already been fixed by Nullsoft? Also, how
come only Nitrane is triggered by this setting? All other decoders work
fine. It would seem like it, that using a value of 8191 is more of a
'workar
> But before I look into this, can
> you do one more thing: compare the .wav headers?
I'd be glad to, only I don't know much about .wav headers, even less about
comparing them.
One thing, though, doing a .wav compare in EAC reports the original .wav
being 0:00:00.004 longer.
Liviu
--
MP3 ENC
Howdy,
> ISO spec says the maximum should be 8191. But as part of huffman
> decoding, you sometimes add 15 to the result, yielding values as large
> as 8206. Right now, LAME (and the ISO dist10 code) will make use of
> the full range: values up to 8206.
>
> The question is, should LAME be modif
Hallo Mark,
Saturday, September 30, 2000, 3:00:50 PM, you wrote:
>>
>> Hi All!
>> Its very needed thing or not?
>> For MP3-hard players or some?
>>
>> Send url please!
>>
>> Alexander
>> RUSSIA
>>
MT> It only needed so the decoder can compute the correct playing
MT> time (and how to seek w
Convert them to RAW format , thus stripping the headers away.
David
Liviu wrote:
>
> > But before I look into this, can
> > you do one more thing: compare the .wav headers?
>
> I'd be glad to, only I don't know much about .wav headers, even less about
> comparing them.
>
> One thing, though,
On Sun, 1 Oct 2000, Michael Mutschler wrote:
> MT> It only needed so the decoder can compute the correct playing
> MT> time (and how to seek within the file) of mp3's encoded with
> MT> VBR. Hardware players may just ignore it.
>
> Not only for this, but to give information about the whole mp3-
