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: The LAME tag (Read 3462 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The LAME tag

Today I decided to RTFM on the LAME tag specifications. So I sat down with UltraEdit, the Windows calculator and the tag specs and the played around for while.

It's a great idea I think, but I think something is missing. Why did they not make it so that it is possible to see all the encoding parameters used. Sure you can see if vbr-old or vbr-mtrh was used. And you can check out the lowpass value. That's cool. But I'd like to be able to see if some crazy switches like --nores, --noshort or -F was used. (okay maybe not crazy, but you get the idea).

Is that because of some technical issues, or is the LAME tag still in development or something?

Also, did anyone write some software to decode the tags? Sure you can use UltraEdit and calc but it's sorta time consuming, and I'm not 31337 enough to read HEX like reading a book.

<edit>

Extra added bonus question:

How do you find the song length (time) of an MP3 file? A friend of mine wants to know.

Byte $B0 gives only the minimum bitrate for VBR files, and bytes $B8-$BB gives only the music length in bytes.

</edit>

The LAME tag

Reply #1 –
Quote
Originally posted by Zalkalin
Today I decided to RTFM on the LAME tag specifications. So I sat down with UltraEdit, the Windows calculator and the tag specs and the played around for while.

It's a great idea I think, but I think something is missing.


I think the tag is an interesting idea as well, but I think that it's poorly implemented.  The reason why is because it stores internal behavior of the mp3 encoder in the file.  I think that's a bad idea because it doesn't allow for future changes and expansion very well.  A prime example of this would be the code level modifications I've made to the --alt-presets.  As it stands, the tag only includes some experimental flags such as nspsytune, nssafejoint, and some others... but the --alt-presets go way beyond that.  With the current system though, you wouldn't be able to see any of that from analyzing the tags.  The system just isn't very dynamic or extensible.

What I think would be much better would be to store the top level commands used, along with a build or version number (aside from other actual useful attribute flags such as the replaygain and musiccrc fields).  For example, you might have something like:

Commands:

--alt-preset standard

Version:

3.91 Stable

From there, it would be possible to compare the behavior of the code with that version, at that point in time against some sort of database.  This way, the entire thing could be dynamic.  No more worrying about what would happen if massive code level changes occur.  Right now, if they did occur, the spec would have to be massively overhauled and it would break older versions.. either that or you'd have to include code in the tag readers to interpret all the older versions, and that would get messy very quickly.

On the other hand, it would be an extremely simple task for the tag reader to include a sort of database file which would be distributed with each new version of lame, that acts sort of like a changelog for the internal behavior of various switches, instead of just hardcoding the values.

If the tag ever comes into wide use, I hope this approach is adopted because the current system is much too rigid, and messy in my opinion, and it's already outdated (considering the --alt-presets and the new flags for nspsytune).

Quote
Is that because of some technical issues, or is the LAME tag still in development or something?


I guess you could say it's still in development...

Quote
Also, did anyone write some software to decode the tags? Sure you can use UltraEdit and calc but it's sorta time consuming, and I'm not 31337 enough to read HEX like reading a book.


Apparently, Roel had some program that read the current implementation of the tags awhile ago, but I don't think it was ever released to the public.

The LAME tag

Reply #2 –
Thanks for speedy reply.

So basically the current LAME tag is a poor implementation of an otherwise great idea. That's too bad. I hope someone decides to redo the tag thing. I wish I could help here

Quote
Originally posted by Dibrom
Apparently, Roel had some program that read the current implementation of the tags awhile ago, but I don't think it was ever released to the public.
I thought about writing some software to read the tag, just to practice my kung-foo, but the VB
  • setup keeps crashing.

  • Yea VB. I know - but I haven't got the balls to start learning C++. VB is so warm and fluffy

The LAME tag

Reply #3 –
The program that Roel is probably using to read these tags is Encspot 1.1 Beta 1.  There was an option in that beta version entitled "LAME HEADER."  In Beta 2 Jon removed that feature because when you tried to read the header where it didn't exist (basically any mp3 that Roel hadn't tagged) Encspot would crash.  Speaking of Jon, where is he anyways?

The LAME tag

Reply #4 –
Quote
How do you find the song length (time) of an MP3 file?


To calculate length in seconds: length = filesize / bitrate

Note: filesize in bytes, bitrate in byte/s! (128000 bit/s = 16000 byte/s)

For CBR, just read the first frame to get the bitrate.

For VBR, read the Xing header to get amount of frames, then calculate average bitrate like this:
bitrate = ((filesize / frames) * frequency) / 144000

144000 is just some "magical" constant, look here for more info:

http://www.id3.org/mp3frame.html

Quote
What I think would be much better would be to store the top level commands used, along with a build or version number


I agree. I don't care if -x or -y -z or where used, but it would be nice to know if a well tuned quality-switch (like --alt-preset standard) was used and not just -V0 alone.