Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: --aps -b192 with 128/160 frames? (Read 5507 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

--aps -b192 with 128/160 frames?

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):
Quote
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?

--aps -b192 with 128/160 frames?

Reply #1
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!


--aps -b192 with 128/160 frames?

Reply #3
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: [Select]
                                 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?

--aps -b192 with 128/160 frames?

Reply #4
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.

--aps -b192 with 128/160 frames?

Reply #5
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?

--aps -b192 with 128/160 frames?

Reply #6
Agreed!  Gabriel?

--aps -b192 with 128/160 frames?

Reply #7
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.

 

--aps -b192 with 128/160 frames?

Reply #8
Quote
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".

--aps -b192 with 128/160 frames?

Reply #9
EDIT: originally replied without fully understanding one previous post.
          I am sorry (mods, could you delete?)
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

--aps -b192 with 128/160 frames?

Reply #10
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.

--aps -b192 with 128/160 frames?

Reply #11
So someone's going to fix this bug?

--aps -b192 with 128/160 frames?

Reply #12
It is now fixed in the current cvs version.

--aps -b192 with 128/160 frames?

Reply #13
Thanks Gabriel!