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: no LAME tag on CBR < 56? (Read 7328 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

no LAME tag on CBR < 56?

I have been lurking for some time trying to educate myself about the mp3 format for a while and this forum has been a great resource. Now I have come across a curious issue that I cannot seem to find any information about anywhere and had to sign up to see if anyone here might have a clue about what is happening here.

Basically I have an application made with actionscript that plays back mp3 files. For a number of reasons I have restrictions on what formats I can use.
Of course bandwidth is a concern, but it's also extremely important that it doesn't sound too good 
So I need to have a bitrate of 24 or possibly 32 kbps, in mono. But I also need to have the info tag to retrieve delay and padding values.
Also it should have a samplerate that is a multiple of 11.025.

Using LAME 3.98.2 or 3.97 I cannot get an info tag on a bitrate lower than 48.
If I use the resample switch on a 48kbps file no info tag is written and LAME never Displays the "Writing LAME tag". With bitrates above 48k the tag is written regardless of if I use the resample switch or not.
 
no tag:
-b <= 40 (24kHz)
-b 48 --resample 22.05
-b 48 --resample 32

tag:
-b 56 --resample 22.05
-b >= 48 (32k)

Also if I use stereo source files and create stereo mp3s LAME tag will be written also on bitrates lower than 40 regardless of if they are resampled or not...so the issue only appears if I use the "m" mode or have mono source files.

I tried with 3.99 alpha 1 and in the same cases where the writing LAME tag doesn't get written with the other versions I instead get the following result:
Quote
D:\Program Files\RazorLame\lame>lame -b 40 -m m source.wav dest.mp3
LAME 3.99 (alpha 1, Nov 19 2008 06:00:42) 32bits (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Autoconverting from stereo to mono. Setting encoding to mono mode.
Resampling:  input 44.1 kHz  output 24 kHz
Using polyphase lowpass filter, transition band: 10548 Hz - 10839 Hz
Encoding source.wav to dest.mp3
Encoding as 24 kHz single-ch MPEG-2 Layer III (9.6x)  40 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
    0/735    ( 0%)|    0:00/    0:00|    0:00/    0:00|  0.0000x|    0:00
00:17--------------------------------------------------------------------------
  kbps      %    %
    0.0                                                                       
Assertion failed: gfc->VBR_seek_table.bag, file libmp3lame/VbrTag.c, line 198

abnormal program termination


Anyone got an idea of my options here?
Is there any way to force LAME to include the LAME tag that I'm missing (-T does not work...I guess it's only for VBR anyway).
Is there a library with old LAME versions I could test to see if it's a bug that does not exist in older versions?
Are there any solutions that can write the LAME tag in existing mp3s?
Is there any software apart from LAME that can encode mp3s with information about padding and delay?

Many thanks in advance for any input!

no LAME tag on CBR < 56?

Reply #1 –
Are you sure that encoding mono material in stereo doesn't write the tag? You do know that joint stereo encoding of mono material wastes almost no bits over encoding as mono?

no LAME tag on CBR < 56?

Reply #2 –
"VBR" header is in fact just an "empty" MP3 frame. LAME's encoder delay/padding values are part of a further extension header, which is even larger.
For your target settings, size of one MP3 frame is simply smaller than size of this header, so it is not written.
Full-quoting makes you scroll past the same junk over and over.

no LAME tag on CBR < 56?

Reply #3 –
Quote from: pdq on
Are you sure that encoding mono material in stereo doesn't write the tag? You do know that joint stereo encoding of mono material wastes almost no bits over encoding as mono?

Thanks...that was a great suggestion but I tested now and when using "-m j" or "-m f" with a bitrate of less than 48 kbps those switches will have no effect and I still get mono files without the LAME tag. 

I did some more testing using a stereo file as source  I must say I don't notice too much of a difference in quality despite the fact that the samplerate is 8kHz for stereo and 16kHz for mono at 24kbps...both sound bad enough at least
But I'm not sure where I got the idea that it will write the LAME tag regardless of if I use the resample switch on stereo files.
I just tried with 24 and 32 kbps and 24 kbps stereo will write LAME tag if it is not resampled. 32 kbps stereo will not write LAME tags at all. 40 and 48 will write if not resampled. 56 kbps will write also when resampled.


Quote from: Yirkha on
"VBR" header is in fact just an "empty" MP3 frame. LAME's encoder delay/padding values are part of a further extension header, which is even larger.
For your target settings, size of one MP3 frame is simply smaller than size of this header, so it is not written.

Thanks...I can't say I have a thorough understanding of the format but that makes sense.
So using the same bitrate but stereo will result in a larger framesize then?
And do you have any idea why one cannot force a mono source to stereo on bitrates below 48kbps?

no LAME tag on CBR < 56?

Reply #4 –
Well, "MP3 file" is just a stream of individual "MP3 frames". People invented the "VBR header" to be able to store at least some kind of length in it (filesize/bitrate no longer worked), but it's masked as an empty normal frame, so that it can be skipped by decoders who do not understand it.

Unfortunately, I don't know much about MP3s, I am a mere consumer. I don't feel I can properly answer your additional questions.
Full-quoting makes you scroll past the same junk over and over.

no LAME tag on CBR < 56?

Reply #5 –
One thing that puzzles me is that if the reason is that the frames are too small to fit the LAME tag on some settings, then how come "-b 48" works while "- 48 --resample 32" doesn't?
Both result in 32kHz sample rate so the frame size should surely be the same...no?

no LAME tag on CBR < 56?

Reply #6 –
Maybe because different bitrate/samplerate combinations are compressed to different MPEG-x Layer III bitstreams.
Quote
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (29.4x)  48 kbps qval=3
Encoding as 32 kHz j-stereo MPEG-1 Layer III (21.3x)  48 kbps qval=3
Encoding as 22.05 kHz j-stereo MPEG-2 Layer III (14.7x)  48 kbps qval=3
Encoding as 11.025 kHz j-stereo MPEG-2.5 Layer III (7.3x)  48 kbps qval=3
Full-quoting makes you scroll past the same junk over and over.

no LAME tag on CBR < 56?

Reply #7 –
Quote from: Yirkha on
Maybe because different bitrate/samplerate combinations are compressed to different MPEG-x Layer III bitstreams.

The thing is that both bitrate and samplerate is the same. "-b 48" results in 32kHz MPEG-1 and obviously "-b 48 --resample 32" as well.

no LAME tag on CBR < 56?

Reply #8 –
Then I have no idea. Please forgive my ineptness, I won't delve into the matter further.
Full-quoting makes you scroll past the same junk over and over.

no LAME tag on CBR < 56?

Reply #10 –
Quote
"-b 48" results in 32kHz MPEG-1


Lame 3.97, 3.98.2 :

lame.exe -b 48 results in 22.05 kHz MPEG-2 file.

no LAME tag on CBR < 56?

Reply #11 –
Quote from: lvqcl on
Quote
"-b 48" results in 32kHz MPEG-1


Lame 3.97, 3.98.2 :

lame.exe -b 48 results in 22.05 kHz MPEG-2 file.

Sorry...I should have clarified.
32kHz is for mono files. So if you have a stereo source it's "-b 48 -m m".

no LAME tag on CBR < 56?

Reply #12 –
Quote
Sorry...I should have clarified. 32kHz is for mono files. So if you have a stereo source it's "-b 48 -m m".


Sorry, I missed this. Still, "lame.exe -b 48 -m m" -- resulting mp3 does have headers, and "lame.exe -b 48 -m m --resample 32" produces bit-identical output. 3.97 and 3.98.2.

no LAME tag on CBR < 56?

Reply #13 –
Quote from: lvqcl on
Quote
Sorry...I should have clarified. 32kHz is for mono files. So if you have a stereo source it's "-b 48 -m m".


Sorry, I missed this. Still, "lame.exe -b 48 -m m" -- resulting mp3 does have headers, and "lame.exe -b 48 -m m --resample 32" produces bit-identical output. 3.97 and 3.98.2.

Hmmm...seems odd if it would be system specific. Are you certain you have the complete LAME tag with ENC_PADDING and ENC_DELAY set?
Otherwise do you get the tag also using lower bitrates?
 

no LAME tag on CBR < 56?

Reply #14 –
Quote from: Psilion on
Quote from: lvqcl on

Quote
Sorry...I should have clarified. 32kHz is for mono files. So if you have a stereo source it's "-b 48 -m m".


Sorry, I missed this. Still, "lame.exe -b 48 -m m" -- resulting mp3 does have headers, and "lame.exe -b 48 -m m --resample 32" produces bit-identical output. 3.97 and 3.98.2.

Hmmm...seems odd if it would be system specific. Are you certain you have the complete LAME tag with ENC_PADDING and ENC_DELAY set?
Otherwise do you get the tag also using lower bitrates?


For 48 kbps file: foobar2000, properties window: <ENC_DELAY> 576, <ENC_PADDING> 1600.
40 kbps file (lame -b 48 ,mono) doesn't have these tags.
BTW "lame --abr 40 -b 40 -F -B 40" => mp3 have these tags.