Description: Identify MP3 Codecs using information about short blocks, scfsi, scalefac_scale, etc.
Keywords: fastenc, Fraunhofer, FhG, Lame, Xing

### Identifying MP3 Codecs

Notes captured by ff123

I didn't do any programming, but I think the topic is of enough interest to feature this as a page on the main site, rather than to relegate it to a one-line entry on my links page.

How does one determine the identity of an mp3 encoder if he doesn't have access to the original .wav file? Naoki Shibata devised the following checklist which he posted on the r3mix.net forum:

> One can guess which encoder is used using MP3 frame analyzer.
> Regarding CBR 128kbps MP3 files :
> Start from 0.
> 0 : Are short blocks used? no -> 1, yes -> 3
> 1 : Are IS frames used? no -> 2, yes -> very old Xing
> 2 : Is scfsi used? no -> old Xing, yes -> new Xing
> 3 : Is the bit reseroir properly used? yes -> 4, no -> bladeenc
> 4 : Is scfsi used? no -> 5, yes -> lame(recent lame also uses scalefac_scale)
> 5 : Is scalefac_scale used? yes->6, no-> unknown
> 6 : Is padding used? no -> FhG(ACM or producer) yes -> FhG(l3enc, fastenc or mp3enc)

[Note: It is important to note that this algorithm is specified at CBR 128 kbit/s. FhG uses intensity stereo at lower bitrates --ff123]

Naoki wrote a command-line program, which can be obtained from his website, http://www.milky.ne.jp/%7Egalaxy/mp3guessenc.html

jondee314 incorporated Naoki's code into a program which uses a Windows Explorer-like interface. You can download his program from his website, http://www.guerillasoft.com/Encspot/

Gabriel Bouvigne suggested the following identifiers in this thread:

> First of all, I personnally think that this detection thing is really nice. I'd also like to see the extented info provided by Naoki's code into an "advanced info" tab in the mad plugin. (Rob, what do you think about it?)
> I have a few suggestions for the detection thing:
> *try displaying a version number instead of just "old". As an example, when we have a Lame file but the string "LAME" isn't found, the result could be "Lame <3.80" instead of "Lame (old)".
> *if there are no short blocks and the file is dual channel, the encoder is probably Shine. (yes, it's not so widespread, but it exists)
> *if no joint and all CRC are false, Blade
> *in the case of FhG, perhaps the original and copyright flags could be used to choose between the FhG flavours
> *FhG's vbr header includes the string "VBRI"
> *I remember seeing somewhere that padding of ancilary data (probably in the first and last frame) could also be used in order to determine the encoder (padding with 0 or F), but it's probably not very reliable.
> *With Lame, when using vbr and the vbr header is present, the Lame version number is always fully present in this vbr header. So it would be better to use this one ot extract Lame version instead of using the last one. It would speed up the process, and prevent a few "Lame .TAG" guessed version numbers because the last one was used and there wasn't enough space to put the version number in the last frame.

Other identifiers, most of them a lot more difficult to incorporate into a program:

- Fraunhofer's MP3Enc and Alternate codecs occasionally have dropouts (see my page, "Dropouts" in FhG mp3enc/Alternate Codecs). It is tedious to go through a file searching for dropouts, and the artifacts are not guaranteed to be present, but if you do see them, you can be virtually certain that MP3Enc or Alternate was used to encode the file.

> Addendum, 2-18-01: QDesign's MVP 2.1 also seems to have dropouts when encoding BlackBird.wav. So I would amend the identification to choose MP3Enc/Alternate if Naoki's algorithm detects FhG and dropouts are present. Otherwise, if Naoki's algorithm detects dist10/other and dropouts are present, I would say it's QDesign's MVP.

- Fraunhofer's MP3Enc (not Alternate) can be identified at 128 kbit/s, using the spectral view of your sound editor, by noting that frequencies never exceed 15 kHz. If someone has overridden the max bandwidth, you won't catch this, but if you do see this type of behavior, it's a sure bet you're looking at MP3Enc. For example, see the Cool Edit spectral view of Steely Dan's Babylon Sisters, below, encoded with MP3Enc31 -qual 9 at 128 kbit/s:

> Codec | Steely Dan's Babylon Sisters
> MP3Enc31 -qual 9, 128 kbit/s |

- If an encoder is identified by Naoki's program as being FhG (l3enc, mp3enc, or fastenc), and it uses joint-stereo at a bitrate of 160 kbit/s or above, there is a good chance it is FastEnc, since mp3enc defaults to stereo for bitrates of 160 kbit/s and above, whereas FastEnc is forced to use joint-stereo for all bitrates.

- Fraunhofer's bad Alternate codec (see Bug in older FhG "Alternate" Codec) can be identified, again by using the spectral view. Compare this plot with the one above for MP3Enc. The base cutoff is somewhere around 13 kHz instead of the normal 16 kHz (or 15 kHz for MP3Enc at 128 kbit/s). One has to be careful, though. If the music has quiet passages with not much high frequency content, it's possible to confuse this spectral plot with another. The key difference is that even with moderately loud passages containing high frequency content, which would normally be encoded by other codecs, the bad Alternate still cuts off at 13 kHz.

> Codec | Steely Dan's Babylon Sisters
> Bad Alternate codec (Cool Edit Pro with MP3 ME plugin) 128 kbit/s |

> Compare the bad Alternate against FastEnc in the spectral views shown below, in which I have expanded the time scale. Near the middle portion of the plot, in moderately loud passages with high frequency content, using the FastEnc codec, energy is allowed up to 16 kHz. In the bad Alternate version, such passages are cut off at 13 kHz.

> Codec | Excerpt from Steely Dan's Babylon Sisters
> Bad Alternate codec (Cool Edit Pro with MP3 ME plugin) 128 kbit/s |
> FastEnc codec (Cool Edit Pro with MP3 ME plugin) 128 kbit/s |

Return to ff123's home page