Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi, I don't know if this is what you're looking for, but my doc contains the following: authors: Dipl.-Ing. Martin Sieler Dipl.-Ing. Ralph Sperschneider Issue: 1.2 04.03.97 Is this what you're after? Regards, Adam Whitehead CEO - Netherworld Media E-mail: [EMAIL PROTECTED] Phone: +61 (889) 279 898 FAX: +61 (889) 273 889 AudioPhilez (http://www.audiophilez.com) - Original Message - From: "Gabriel Bouvigne" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 20, 2000 9:52 PM Subject: Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat] > > > > There is a Word document floating around, published by > > > Fraunhofer, called "MPEG Layer3 Bitstream syntax and decoding" > > > It is much more usefull to decoder writers than the ISO docs. > > > > Anybody have a copy of this? I'd love to see it. > > > > Thanks, > > Alex > > I'd also like a copy of a good version of this document. Mine is > incomplete and most tables are completely messed. > > Regards, > > -- > > Gabriel Bouvigne - France > > www.mp3-tech.org > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
> > There is a Word document floating around, published by > > Fraunhofer, called "MPEG Layer3 Bitstream syntax and decoding" > > It is much more usefull to decoder writers than the ISO docs. > > Anybody have a copy of this? I'd love to see it. > > Thanks, > Alex I'd also like a copy of a good version of this document. Mine is incomplete and most tables are completely messed. Regards, -- Gabriel Bouvigne - France www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
> > Howdy All, > > I recently finished completely overhauling the ISO 'dist10' LSF decoder to > extract a layer-III only player for work. In the process, I discovered a > few bugs/inconsistencies in/between the 'dist10' distribution and ISO/IEC > 11172-3 and 13818-3. I don't know if they would account for the differences > you are reporting, but they certainly might contribute. > > Here's what I found: > Here are a few other bugs that you might be interested in. They were discovered by (IIRC) Robert, Iwasa, Takehiro and Leonid: ISO/mpg123/mpglib: 24khz scalefactor band index table for long blocks, the number "330" should be "332". This will actually cause the decoder to choke on the whole frame so it should be easy to detect. (unless the encoder was also incorrectly using 330 :-) mpglib: There were several scsfi bugs in mpglib that didn't seem to be in mpg123. I dont know if these bugs are in the ISO code, and fixed in mpg123 after mpglib was created, or if the bugs were introduced in the creation of mpglib. There was also a bug in the ISO encoder which could easily be in the decoder: It was reversing the order of the individual quadruples in the count1 region. This bug only effects the highest frequencies, and is particularly insidious because it produces small flaws which could be attribted to compression artifacts. Another bug in almost all the windows players: They dont allow the samplerate to change within a bitstream. (for example, if a 44.1 and 22.05 mp3 file are concatenated into one file) Responce various from crashing to doing a micky mouse impersonation. There is a Word document floating around, published by Fraunhofer, called "MPEG Layer3 Bitstream syntax and decoding" It is much more usefull to decoder writers than the ISO docs. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Howdy All, I recently finished completely overhauling the ISO 'dist10' LSF decoder to extract a layer-III only player for work. In the process, I discovered a few bugs/inconsistencies in/between the 'dist10' distribution and ISO/IEC 11172-3 and 13818-3. I don't know if they would account for the differences you are reporting, but they certainly might contribute. Here's what I found: 1) In the joint stereo processing function, in the intensity stereo block, for both mixed and short there is a bug in the code - after the lower frequency bands are handled, the highest band, for which no scalefactors are transmitted, is supposed to be filled with the values for the next lowest band. However the code instead writes over the values in the 11th band by mistake, and leaves the 12th (highest) band uninitialized. This is clearly wrong, and fixing it makes a difference in the highest frequencies of short/mixed intensity coded blocks. 2) In the requantization function, the boundary for mixed, LSF blocks is wrong. For MPEG-1, it is band 8, but for MPEG-2, it should be 6. I've never encountered any mixed blocks, so I only found this while simulating mangled input bitstreams, where it causes hangs/crashes. The same error is repeated in the LSF decode scalefactors function (8 for 6), and this time it is also a discrepancy with the spec, which says 6. 3) The spec has a bug - when reading side info and window_switching_flag is true, the spec says that region1_count can be set to 36. This is totally false. The 'dist10' code has the correct formulation, which is 20 - region0_count. 4) Finally, the spec is very misleading about the order of processing. It lists joint stereo processing as occurring after reorder. However, the 'dist10' code does reorder after joint. I'm sure you could reverse this, but it makes a big difference in the joint stereo block. If you just naively switch them, everything seems OK until you try to decode an intensity coded block, at which point you get very different results. I should point out that in testing I also observed numerous non-trivial discrepancies between the output of L3dec (v.274) and the ISO code when using LSF (i.e. MPEG-2's lower sampling frequencies) (or maybe intensity - they typically switch on at the same time) which I could not account for with the above buggage (actually, I didn't try bug 4). Either there are further (undetected) bugs in 'dist10', or ISO and FhG disagree on how LSF(/intensity) should be handled... If anyone has any similar experience, I'd appreciate their comments, Alex > -Original Message- > From: Matthew Lloyd [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 18, 2000 4:54 PM > To: [EMAIL PROTECTED] > Subject: [MP3 ENCODER] Decoder quality comparison [quite detailed - > sorry if repeat] ... > My first discovery was that out of the four WAV files I had, > three were > almost exactly identical. The decoded audio from aE4 and the > Fraunhofer > WinAmp codec was byte-by-byte identical with that from l3dec > apart from the > occasional 1-bit quantization error (v occasional - about 2 > or 3 a second > I'd guess). However the Nitrane WAV, whilst identical in almost every > respect and certainly identical below 13kHz, showed differences in the > 13khz-16khz band. ... > This is clearly a bug, either in fraunhofer's code or > nitrane's code. I > could not hear the differences (untrained ear) nor could I > verify which was > more 'correct' to the mp3 format since I know nothing of > this. My immediate > conclusion would be that Nitrane has a bug that is causing > these errors. > However, since Nullsoft have licensed Fraunhofer's mp3 decoding code > already, for version v2.2, and since the v2.6 Nitrane > decoder's about box > still has a panel crediting the mp3 decoder license to > Fraunhofer, why would > Nullsoft exchange a perfectly good piece of Fraunhofer code > for Nitrane code > that produces these bugs? Are these bugs actually original > bugs in the ISO > implementation upon which presumably Fraunhofer's code is > based? Are these > differences worry-worthy? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi Matthew. Interesting analysis. Just one question. What do you mean by > WinAmp's EQ sucks bigtime. They all have the same frequency response. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi peeps, I know this is MP3-encoder but I couldn't find any place more suitable to post the results of some decoder testing I've been doing over the last couple of days. I took a fairly complex track (Pat Metheny's Imaginary Day title track in fact) ripped from CD at 44.1khz 16bit stereo, and encoded it using Fraunhofer's MP3Enc v3.1 to a 256kbit MP3 file using the '-qual 9' setting. I then proceeded to decode the track using various decoders. The decoders I tested were l3dec v2.74, Sonique aE4 (from v1.51.0) and two Winamp decoders, the first from v2.2 (the first release with the Fraunhofer codec) and the second from v2.6 (Nitrane). I then compared the output WAV files to discover any potential differences! To compare the audio files, I found a suitably complicated 10-second portion of audio in the original WAV file, then identified by inspection a suitable reference point at the start of this section, which turned out to be a particular peak in the waveform that was clearly identifiable. Using CoolEdit 2000 I marked the corresponding sections in the decoded WAVs to the exact sample. This allowed me to subtract one of the WAVs from the other and thereby do a direct comparison. My first discovery was that out of the four WAV files I had, three were almost exactly identical. The decoded audio from aE4 and the Fraunhofer WinAmp codec was byte-by-byte identical with that from l3dec apart from the occasional 1-bit quantization error (v occasional - about 2 or 3 a second I'd guess). However the Nitrane WAV, whilst identical in almost every respect and certainly identical below 13kHz, showed differences in the 13khz-16khz band. These differences appeared in the subtracted audio as single isolated spectral components, of very short duration (perhaps 0.05s) and constant frequency. They were distributed quite evenly between the left and right channels, maybe 5 per channel per second. Each had an amplitude of perhaps -60db. The question now was whether these were a) components missing from l3dec's output; b) components missing from nitrane's output; c) components present in both but at different amplitudes or d) something else. A little detective work was in order. I put CEP 2000 into spectral view and captured the spectrums into Paint Shop Pro, where I could subract then from each other as images. What I discovered was that the components were always present in both, but were either at different amplitudes, or at slightly different positions - the nitrane components were roughly 50/50 too far ahead or too far behind the l3dec components. This is clearly a bug, either in fraunhofer's code or nitrane's code. I could not hear the differences (untrained ear) nor could I verify which was more 'correct' to the mp3 format since I know nothing of this. My immediate conclusion would be that Nitrane has a bug that is causing these errors. However, since Nullsoft have licensed Fraunhofer's mp3 decoding code already, for version v2.2, and since the v2.6 Nitrane decoder's about box still has a panel crediting the mp3 decoder license to Fraunhofer, why would Nullsoft exchange a perfectly good piece of Fraunhofer code for Nitrane code that produces these bugs? Are these bugs actually original bugs in the ISO implementation upon which presumably Fraunhofer's code is based? Are these differences worry-worthy? Hope this is of interest to somebody. I also did some encoder quality tests and discovered that I could not coax MP3ENC to encode the 16-22kHz band particularly well - it would occasionally code components up to 20kHz but in places where it mattered, for example drum attacks, it seemed not to bother. LAME 3.70 did much better in this area. As I can hear some components above 16kHz and since LAME is about 10 times faster on my machine I'm sticking with LAME. Nice work guys :) If anybody's really interested I'll put up some pictures of the results somewhere. The basic conclusion is: there is no major difference between any of the MP3 decoders out there, except to say that that WinAmp's EQ sucks bigtime. They all have the same frequency response. Matthew -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
