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
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
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 within the file) of
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, doing a
