Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
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 like this: dist10 uses 8206 after adding 15 to big_values and LAME used to add 15 to 8206? I'm confused. Does this mean LAME complies to the ISO spec now or was the ISO spec incorrectly specified? -Youri
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
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 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] 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 like this: dist10 uses 8206 after adding 15 to big_values and LAME used to add 15 to 8206? I'm confused. Does this mean LAME complies to the ISO spec now or was the ISO spec incorrectly specified? -Youri 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 modified to limit this range to 8191. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
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 'workaround' to the Nitrane bug, but the actual bug is still present. Since Nullsoft said they fixed it now, I don't think LAME has to lose quality just to help out users of older versions of Winamp. Just my opinion, I could be wrong. :) -Youri -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
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 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Xing Tag - what is it?
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 mp3's encoded with MT VBR. Hardware players may just ignore it. Not only for this, but to give information about the whole mp3-file when it is encoded with VBR. The usual way to get the information about a mp3-file is to look at the bitrate first MP3-Frame(s) and then calculate the playing time from filesize/bitrate. This works good as long as you don't have a VBR encoded file. Usually these files start with a low bitrate frames (~32kb) and the information is totally wrong then. The Xing-Header is encoded as a (invalid I think) MP3-frame, and stores information about the mp3-data. Since my program displays icons for the mp3-files according to the bitrate, this gives wrong information on VBR-MP3-files without the Xing header. btw, how about a "--id3v2PaddingSize" option, where you can specify the padding size of the ID3-tag, so the editing of the mp3-files can be faster? No long copying of the complete MP3-data will be necessary on small changes then. -- Best regards, Michaelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
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 .wav compare in EAC reports the original .wav being 0:00:00.004 longer. Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
