IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
--aps -b192 with 128/160 frames?, How did this happen?
getID3()
post Oct 7 2003, 23:00
Post #1


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



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?


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post
ViPER1313
post Oct 7 2003, 23:23
Post #2





Group: Members
Posts: 271
Joined: 19-August 02
From: Maryland
Member No.: 3109



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 rolleyes.gif . Good luck!

This post has been edited by ViPER1313: Oct 7 2003, 23:29
Go to the top of the page
+Quote Post
magic75
post Oct 8 2003, 07:44
Post #3





Group: Members
Posts: 511
Joined: 2-December 02
Member No.: 3959



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
Go to the top of the page
+Quote Post
getID3()
post Oct 8 2003, 16:55
Post #4


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



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? smile.gif


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post
john33
post Oct 8 2003, 17:47
Post #5


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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. wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
getID3()
post Oct 8 2003, 17:58
Post #6


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



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?


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post
john33
post Oct 8 2003, 18:05
Post #7


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



Agreed! wink.gif Gabriel?


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
harryzonker
post Oct 8 2003, 19:29
Post #8





Group: Members
Posts: 26
Joined: 23-July 02
Member No.: 2751



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.
Go to the top of the page
+Quote Post
getID3()
post Oct 9 2003, 03:51
Post #9


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



QUOTE (harryzonker @ Oct 8 2003, 10:29 AM)
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".


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post
AtaqueEG
post Oct 9 2003, 06:38
Post #10





Group: Members (Donating)
Posts: 1336
Joined: 18-November 01
From: Celaya, Guanajuato
Member No.: 478



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


--------------------
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
Go to the top of the page
+Quote Post
Gabriel
post Oct 9 2003, 09:54
Post #11


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
getID3()
post Oct 9 2003, 15:50
Post #12


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



So someone's going to fix this bug? smile.gif


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post
Gabriel
post Oct 16 2003, 13:53
Post #13


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



It is now fixed in the current cvs version.
Go to the top of the page
+Quote Post
getID3()
post Oct 16 2003, 14:39
Post #14


getID3() developer


Group: Developer
Posts: 252
Joined: 20-September 02
From: Kingston, ON
Member No.: 3413



Thanks Gabriel! smile.gif


--------------------
getID3() = PHP audio & video metadata parser: http://getid3.sourceforge.net
Current version: v1.7.0 (released January 19, 2004)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th July 2014 - 21:48