Hey,

I was wondering.. Since an mp3 file encoded with lame has a 'lame tag', which contains some info about the encoding (encspotpro I heard does this), would it be possible to, sum up the info in the lame tag and display what lame settings were used to encode the file?

I'm not sure if the lame tag contains info on every possible command line parameter, but then again, the --alt-preset settings aren't just a combination of lame command line parameters (as opposed to --r3mix).

So.. I would assume that it would be possible to write a program that reads the lame tag, and for every file in a directory, display the lame settings used to encode those files. It would be a way to know you're dealing with napster-type quality (but this you will know using MP3Utility or EncSpot), decent quality (--r3mix) or what-it-should-be quality (--ap settings).

Any ideas/comments?

Yes, you can use encspot to sort of "guess" which settings were used. No, it doesn't work for --alt-preset though because the internal settings which are enabled by the alt-preset, the LAME tag doesn't even understand or include in it's specification. The LAME tag is kind of useless then for trying to determine whether an mp3 was encoded with quality settings or not.

Thanks for the swift reply - answers my question..

Would it be madness to include an extra field in the lame tag called "--alt-preset " which would be filled in with whatever the preset was, or in the case of alt-preset not being used, leave the field empty?

In order to raise standards in audio compression, it would be a nice move to get rid of badly encoded music. Delete it. In order to do that, you'd have to know what you're dealing with. That's why I asked..

Hrmm.. well it might be possible to do this but it would require modifying the LAME tag specification and it would really be quite a kludge I think.

Personally, I think the LAME tag specification and the way it works kind of sucks. It wasn't designed to be very forward compatible at all. All of the values are "hard coded" and of course the only things which were included where the internal options available when the specification was being written. A good bit has changed since then that the tag doesn't account for.

To be truly useful, I think a new system would need to be designed from scratch.

I've talked about my thoughts on a system like this before in previous threads, they'd probably come up pretty easily if you searched for mention of "LAME tag" by "Dibrom"

and how is with that for ogg? is it possible to detect the -q settings somehow? (or did i miss something)

tia, smok3

p.s. btw, the search icons (gifs, jpgs?) - pictures are not loading for me on the 1st page here (news section).

Winamp's in_vorbis plugin displays the nominal bitrate the file was encoded at in the file info box.

ic, well i thought that term 'quality oriented' actually means something, tnx.

But from the nominal bitrate, you can work out the -q setting used:



I don't know what in_vorbis displays when ABR was used, but at least with VBR encoded files, you know exactly how they were encoded if you know the nominal bitrate.

ok, tnx, this seems like enough info at least for improved abr in ver 1.

btw: any1 noticed the huge difference between the offical oggenc win binary and the one on rarewares? (its like 1meg vs 200kb) is that really only a compiler difference?

No, it's not compiler difference. For some weird reason official oggenc.exe and oggdrop.exe binaries aren't compressed at all, only oggdropxpd.exe and ICL compiles are.

Your email do not longer work.
I got the error message "unknown user".

So it seems Thanks for telling, I'll try to figure out what's wrong.

I just want to throw my $.02 in. Instead of looking for tags that tell you what the quality is (or might be), shouldn't you just listen to it and decide if it's up to your golden ears? IMHO, if it sounds good, it's good enough for me.

What you are promoting with your two cents, are 'corporate standards'. Not 'quality standards'. Something that 'sounds good'. That's exactly the Xing codec. It 'sounds good'. But it's not what it should sound like.

It might sound good, but maybe that's only because you never heard the original. The difference might surprise you.

Also, why would you accept anything _but_ the full potential of the compression format? If you do, I'd say get Audiocatalyst. It makes mp3's really fast. Or why just not use Windows Media Player; I heard the latest version can also make mp3's and will do so at 56 bitrate. Standard. It sounds 'alright'. Corporate standards. As fast as possible, with the lowest cost. In this case cost would be the effort you put in trying to find the best way to archive music in a compressed format.

The difference between these standards is something like a pair of 'shoes' made by bloody sweatshop Nike and a pair of shoes made by the guy on the corner, a craftsperson. Or even better: the difference between a factory-made classical guitar that costs 83$ or a handmade classical guitar that costs 25 times as much. Or the difference between real food and the things they sell in supermarkets that have serious number of additives in their ingredients.

Excuse me, but I prefer the real music - if you're throwing out a whole bunch of information by compressing it, you might want to be careful what it is you're throwing out. That's why it would be handy to know what settings were used when encoding the tracks.

If I would like to archive music in a compressed format, I do not want something that 'sounds like' what it was, but I want to hear what it really is and should be.

Each person has hers/his own preferences.

When you buy your next car, don't ask what size the engine is, or how much power it has. Just drive it, and if it feels ok, then don't worry about it

Actually, I think it would be great if the tagging feature was able to tell me exactly what encoder and settings were used. I inderstand that is pretty much out of the question with the MP3 format.