--aps -b192 with 128/160 frames?, How did this happen? Options

[getID3()]

I came across a sample file that I'm having trouble figuring out how it was encoded. According to the LAME tag, it's encoded with LAME v3.92 and while v3.92 doesn't actually store the preset used, according to the rest of the info in the LAME tag it appears to be encoded using --alt-preset standard (vbr_quality = 78; vbr_method = vbr-old / vbr-rh; noise_shaping = 2; stereo_mode = joint; ath_type = 4; lowpass = 19000). The problem is that the LAME tag also says that a minimum bitrate of 192kbps was specified, and yet the actual bitrates are distributed like this (which looks like normal --aps):

128 -> 4
160 -> 963
192 -> 2658
224 -> 817
256 -> 246
320 -> 65

I haven't been able to replicate how the LAME tag has minimum bitrate of 192 but 128 and 160 frames appear in the file. I've tried:
--alt-preset standard -b 192
--alt-preset 192
--abr 192

Any ideas anyone?

[ViPER1313]

My guess is that it was encoded w/ a dll version of v3.92, like the one found in CDEX. My guess is that the person selected the APS settings, and also selected a minimum bitrate of 192kbps (I know you can do this in CDEX.) It will not effect the output of the file at all - it will be a standard APS file - it MAY affect the value in the LAME tag though..... I don't have CDEX installed at the moment, so I can't test the theory. Hope this helps.

Edit - Installed and tested w/ CDEX v1.51, my above theory does not seem to be true. Setting a minimum bitrate of 192kbps actually does force a min bitrate of 192....so I guess my guess was wrong . Good luck!

This post has been edited by ViPER1313: Oct 7 2003, 23:29

[magic75]

This can happen if you use EAC to rip with encoder scheme "Lame MP3 Encoder" and 192 as minimum bitrate in the dropdown list. Check out cOCo and Volcanos post here:
http://www.hydrogenaudio.org/forums/index....t=25#entry67461

[getID3()]

Aha! Thank you magic75! I just tested with EAC and LAME 3.92 and I could replicate my problem. I ripped a WAV using EAC and then compressed it with --alt-preset standard as the Additional Command Line Options and first 160 then 224 in the bitrate dropdown. Unlike what cOCo said, my files were NOT identical (224kbps vs. 230kbps average on the sample track I used). And the appropriate number (160 or 224) shows in the minimum-bitrate field of the LAME tag. Hmm - I just tried it once more with 192 this time, and the 192 and 224 versions come out with an identical bitrate distribution.

I've experimented a little with command-line parameter order, and this is what I found:

CODE

                                Minimum Bitrate      
       command line             LAMEtag  actual
--alt-preset standard -b192 -h  192kbps  192kbps
--alt-preset standard -h -b192  192kbps  192kbps
-b192 --alt-preset standard -h  192kbps  128kbps
-b192 --alt-preset standard     192kbps  128kbps
-b192 -h --alt-preset standard  192kbps  128kbps
-h -b192 --alt-preset standard  192kbps  128kbps

So to interpret that:

• If -b??? is specified, it's stored in the LAME tag all the time
• If -b??? is specified before --alt-preset standard (and I assume other presets too, but I haven't tested) it's ignored and the preset's minimum of 128 is used
• If -b??? is specified after --alt-preset standard (and I assume other presets too, but I haven't tested) it's respected and the preset's minimum of 128 is overidden by whatever you specify

I'm not sure if this should really be called a bug, but I'd definitely classify it as unexpected behaviour. I think the result should be the same whether you say --alt-preset standard -b192 or -b192 --alt-preset standard. But what is a bug is the fact that the minimum bitrate as stored in the LAME tag is not neccesarily the same one that LAME used when comrpessing!

Can someone look into the LAME source and fix this please?

[john33]

This is not a bug, it is intended to work this way. If you specify any setting before the preset that the preset will itself set, then it will be changed by the preset. Similarly, if you specify a setting after the preset, it will alter the value set by the preset. However, the moral of the story really is that if you want the full value of the effort that was put into tuning the presets, don't mess with them, the chances of improving on them without very detailed knowledge are almost zero.

[getID3()]

The fact that --alt-preset standard overrides -b192 is not a bug, that's fine.

What is a bug is that -b192 --alt-preset standard will produce a file that has a minimum bitrate of 128, but with a minimum bitrate of 192 specified in the LAME tag. That's not right - whatever LAME uses should be what LAME stores in its header, right?

[john33]

Agreed! Gabriel?

[harryzonker]

As long as it is understood that arguments later in the command-line override earlier arguments by design then there is no bug as I see it.

However, there is a minor bug resulting from this feature. If you use, for example, the command-line "-b 192 --alt-preset standard" the Lame tag in the encoded file declares that the ABR Bitrate is 192 even though no ABR setting was used. Now if you had used "--alt-preset standard" the Lame tag declares ABR Bitrate is unknown.

This is the reason for some of the confusion here and why someone might blame EAC for the ABR difference.

When a user specifies "Lame MP3 Encoder" in the EAC dialog tab for External Compression, EAC adds "-b 192" to the command-line when "192 kBit/s" is selected in the bit rate drop down box. **This bit rate setting is added before any additional command-line options the user has specified.** If, instead, a user specifies "User Defined Encoder" then nothing is added to the command-line for the bit rate drop box regardless of what is selected. The only difference that results between these two encodings is that the ABR Bitrate is declared in the same way as above.

[getID3()]

for example, the command-line "-b 192 --alt-preset standard" the Lame tag in the encoded file declares that the ABR Bitrate is 192 even though no ABR setting was used. Now if you had used "--alt-preset standard" the Lame tag declares ABR Bitrate is unknown.

Not quite - the same LAME tag field is used for ABR bitrate if the file is ABR, or Minimum Bitrate if the file is CBR or VBR. See http://gabriel.mp3-tech.org/mp3infotag.html under "byte $B0".

[AtaqueEG]

EDIT: originally replied without fully understanding one previous post.
I am sorry (mods, could you delete?)

This post has been edited by AtaqueEG: Oct 9 2003, 06:42

[Gabriel]

As explained, the behavior of Lame is the one intended.
However, you are right about the Lame tag: in this case it could be called a bug.

[getID3()]

So someone's going to fix this bug?

[Gabriel]

It is now fixed in the current cvs version.

[getID3()]

Thanks Gabriel!