Menu
▾
▴
#51 lame -t flag
I have a large collection of MP3 files encoded with lame.
I need to be able to play the files on Android, but I'm having this issue :
https://code.google.com/p/android/issues/detail?id=158627&thanks=158627&ts=1425655288
Is there an easy way to remove the Lame info/xing tag data without re-encoding everything again ?
Br
Henrik
You can use some media player on Windows(and others) to change the tag.
Some players support some types of tagging data.
ID3v1, ID3v2.3, ID3v2.4, APE are widely used types.
You can try Windows Media Player, MP3Tag, foobar2000 to change/modify the tag.
No Linux/commandline tools available ? I have thousands of audiobooks I need to fix, I would really like to be able to script my way out of it :-)
Br
Henrik
This is unusual.
The XING tag (created originally by the encoder that had such name and which was used on VBR files) has a seek table, which 100 jump positions (so very coarse if the file length is long, but a good program would use the table as a "position from where to seek to" instead of seeking from start of file).
The LAME tag uses the same mechanism than the XING tag, but can be applied to CBR files.
When LAME creates an VBR file, it adds a XING tag, with additional information related to LAME. When it creates a CBR file, it simply writes a LAME tag (which does not have the XING name, and does not include the seeking table).
It also adds another feature which is "correct length", by telling the decoder to skip several samples from the beginning and end (which are added by the encoding and decoding processes. In any case, its just hundreds or samples only).
The bug that you link to, shows a file with a duration of 3 hours and 17 minutes, and a "seek error" of 20 seconds. That's a seek error of 0.17%.
What I am guessing is that the seeking in android is implemented depending on what it knows about the file, and might seek by time or by bytes depending on that.
Anyway, I don't think you will find much programs that are able to remove the tag. In fact, the ones I know can recalculate and reapply those tags, but not remove them completely.
At last, which is the program really, that the seeking is "off" by several seconds on an hour+ long audio? (Which program has such a precise seeking?) Or that when seeking to any position it always ends as if it has placed at the end? I don't recall having any issues on My Samsung Galaxy III. (OS 4.1.2)
Ticket moved from /p/lame/bugs/446/
It is not a bug in LAME.
Last edit: Robert Hegemann 2017-08-22