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>

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).



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



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.

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

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 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?

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



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.