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

LAME Tag Reader

Reply #25 –
Quote
Quote
And I can't imagine the LAME Tag spec is likely to change.

It is. There is an issue with the replaygain values in the current version.

I stand corrected.  At what point will this new revision be used?  Has the spec been written yet?

This raises another question: the current revision of the LAME Tag spec is 1 and this is the spec I have based LameTag.exe on.  Was revision 0 used in any publicly released encoder and if so is there a spec available for that revision, so I can get my utility to read those tags correctly too?

LAME Tag Reader

Reply #26 –
Did some tests with LameTag 0.2.0 beta & LAME 3.94 Alpha 15:

--preset standard shows: <not recognised: internal enum 480>
--preset extreme shows: <not recognised: internal enum 500>

Could it be that LAME 3.94 is writing the values wrong?

When encoded with LAME 3.90.3 and 3.93 (both from rarewares) the values are displayed correctly.


This is kinda old but I'm replying here instead of the other thread:

Quote
Searching the forum it seems that the only tool to read the "Preset Used" part of this tag is Frontah.  And this (release 0.92 beta) seems to read this incorrectly: preset standard and preset medium both show up as "unknown (768)".


It's been corrected now (In Frontah) and will be in next release. Thanks for reporting the error, although it was only because of this new thread I read that old one

LAME Tag Reader

Reply #27 –
Quote
I stand corrected. At what point will this new revision be used?

I don't know yet.

Quote
Has the spec been written yet?

Not yet.

Quote
This raises another question: the current revision of the LAME Tag spec is 1 and this is the spec I have based LameTag.exe on. Was revision 0 used in any publicly released encoder and if so is there a spec available for that revision, so I can get my utility to read those tags correctly too?

In the specs it is written rev1, but in fact it is rev0 (my fault). The spec has evolved since the first rev0, but is fully compatible, so I kept using rev0 in Lame.

Quote
Could it be that LAME 3.94 is writing the values wrong?

No, this is made on purpose.

The presets of Lame 3.94 are:

Code: [Select]
    /*values from 8 to 320 should be reserved for abr bitrates*/
    /*for abr I'd suggest to directly use the targeted bitrate as a value*/
    ABR_8 = 8,
    ABR_320 = 320,

    V9 = 410, /*Vx to match Lame and VBR_xx to match FhG*/
    VBR_10 = 410,
    V8 = 420,
    VBR_20 = 420,
    V7 = 430,
    VBR_30 = 430,
    V6 = 440,
    VBR_40 = 440,
    V5 = 450,
    VBR_50 = 450,
    V4 = 460,
    VBR_60 = 460,
    V3 = 470,
    VBR_70 = 470,
    V2 = 480,
    VBR_80 = 480,
    V1 = 490,
    VBR_90 = 490,
    V0 = 500,
    VBR_100 = 500,


Named presets are aliased to -V values.

LAME Tag Reader

Reply #28 –
It seems this has only changed in a15.  a14 stores the 1001 for preset standard but a15 stores 480.

Does this mean there is no longer any way from the LAME Tag to determine whether a preset was used, as the Vx number doesn't necessarily indicate a particular preset?  If this is the case it seems unfortunate as it is already possible to determine the Vx number from the Quality field.

LAME Tag Reader

Reply #29 –
Quote
Does this mean there is no longer any way from the LAME Tag to determine whether a preset was used, as the Vx number doesn't necessarily indicate a particular preset?


You can still determine the preset, as Vx value mean that a preset was used.
Try "--preset standard test.wav" and "-V2 test.wav".

LAME Tag Reader

Reply #30 –
But, for example "--preset medium test.wav" writes the value 460 (mapping to V4) in the preset field.  But "-v -b 224 test.wav" also writes 460 into that field and yet this command line has nothing to do with preset medium.  So if I write LameTag.exe to display "preset: medium" when it sees the value 460 it will be giving incorrect information for this second file.

LAME Tag Reader

Reply #31 –
Quote
But, for example "--preset medium test.wav" writes the value 460 (mapping to V4) in the preset field. But "-v -b 224 test.wav" also writes 460 into that field and yet this command line has nothing to do with preset medium. So if I write LameTag.exe to display "preset: medium" when it sees the value 460 it will be giving incorrect information for this second file.


-v is using the default -Vx value, which is 4, so the following lines are equivalent:

*--preset medium -b 224
*-V4 -b 224
*-v -b 224

So I think that in this case, the information is correct.

LAME Tag Reader

Reply #32 –
Quote
Quote
Searching the forum it seems that the only tool to read the "Preset Used" part of this tag is Frontah.  And this (release 0.92 beta) seems to read this incorrectly: preset standard and preset medium both show up as "unknown (768)".


It's been corrected now (In Frontah) and will be in next release. Thanks for reporting the error, although it was only because of this new thread I read that old one

Sorry, should have emailed you.

LAME Tag Reader

Reply #33 –
Quote
Quote
But, for example "--preset medium test.wav" writes the value 460 (mapping to V4) in the preset field. But "-v -b 224 test.wav" also writes 460 into that field and yet this command line has nothing to do with preset medium. So if I write LameTag.exe to display "preset: medium" when it sees the value 460 it will be giving incorrect information for this second file.


-v is using the default -Vx value, which is 4, so the following lines are equivalent:

*--preset medium -b 224
*-V4 -b 224
*-v -b 224

So I think that in this case, the information is correct.

OK, that makes sense.

The old method of storing preset values used to differentiate between fast and normal presets eg.  standard = 1001, fast standard = 1004.  For both of these presets the value stored is now 480.  Is there any way now to determine whether a fast preset was used?

LAME Tag Reader

Reply #34 –
Quote
Is there any way now to determine whether a fast preset was used?

If you want you can use the vbr method field (byte $A5)

LAME Tag Reader

Reply #35 –
Quote
Quote
Is there any way now to determine whether a fast preset was used?

If you want you can use the vbr method field (byte $A5)

So 3 (vbr old / vbr rh) is a normal preset encode and 4 (vbr mtrh) is a fast one?

Is 5 (vbr mt) ever used?

Also, I have found the following mappings between named presets and Vx values: extreme = 500, standard = 480, medium = 460, portable = 450.  Are there any I've missed?

LAME Tag Reader

Reply #36 –
Quote
Also, I have found the following mappings between named presets and Vx values: extreme = 500, standard = 480, medium = 460, portable = 450. Are there any I've missed?


Code: [Select]
    /*translate legacy presets*/
    switch (preset) {
    case MEDIUM: {
        preset = V4;
        lame_set_VBR(gfp, vbr_rh);
        break;
    }
    case MEDIUM_FAST: {
        preset = V4;
        lame_set_VBR(gfp, vbr_mtrh);
        break;
    }
    case STANDARD: {
        preset = V2;
        lame_set_VBR(gfp, vbr_rh);
        break;
    }
    case STANDARD_FAST: {
        preset = V2;
        lame_set_VBR(gfp, vbr_mtrh);
        break;
    }
    case EXTREME: {
        preset = V0;
        lame_set_VBR(gfp, vbr_rh);
        break;
    }
    case EXTREME_FAST: {
        preset = V0;
        lame_set_VBR(gfp, vbr_mtrh);
        break;
    }
    case INSANE: {
        preset = 320;
        break;
    }
    }
    


Btw, do you know that there is a web interface for cvs on sourceforge?

LAME Tag Reader

Reply #37 –
Quote
Also, I have found the following mappings between named presets and Vx values: extreme = 500, standard = 480, medium = 460, portable = 450.  Are there any I've missed?

3.94a14 uses the 100x-style preset ids
3.94a15 (Oct 21 2003) also uses 100x-style preset ids, adding 1010 for "portable" and 1015 for "radio"
3.94a15 (Nov 12 2003) moves to the 400-500 style of preset ids, as you mentioned. Insane is mapped to 320, radio is 430, you have the rest.

Quite frankly I liked the 100x-style of preset ids, and don't like the new style. As phwip said, it's possible to confuse a named preset with an unnamed preset that happens to generate the same value.

LAME Tag Reader

Reply #38 –
Here is release 0.2.1 beta which adds reading of stored preset values from LAME 3.94a15 and above.

EDIT: now hosted at http://www.silisoftware.com/applets/LameTag

LAME Tag Reader

Reply #39 –
And here's the source code (Delphi)

EDIT: now hosted at http://www.silisoftware.com/applets/LameTag (the main zip file includes the source)

LAME Tag Reader

Reply #40 –
Quote
Quite frankly I liked the 100x-style of preset ids, and don't like the new style.


The 100x style has a problem: hierarchy.

Code: [Select]
    STANDARD_FAST = 1004,
    EXTREME_FAST = 1005,
    MEDIUM = 1006,
    MEDIUM_FAST = 1007,


Do you think that the order is logical? I personnally don't.

Quote
As phwip said, it's possible to confuse a named preset with an unnamed preset that happens to generate the same value.


I think that there is no "unnamed preset that happens to generate the same value.". They are identical. It is not a matter of luck that the result is the same, it is just that presets are always used.

LAME Tag Reader

Reply #41 –
Quote
Quote
As phwip said, it's possible to confuse a named preset with an unnamed preset that happens to generate the same value.


I think that there is no "unnamed preset that happens to generate the same value.". They are identical. It is not a matter of luck that the result is the same, it is just that presets are always used.

Yes, I can see the point of this now.  The presets in 3.94 are simply mappings onto particular Vx values.  So the new way of storing the preset values does make sense.

LAME Tag Reader

Reply #42 –
Quote
And here's the source code (Delphi)


*I think that you should not bother with portable or radio presets. They were only used in alpha, and not meant for production use. It was just an handy way to call those presets when the Vx values were not yet calling presets.

*In any vbr Vx value, there can be a "fast mode"
I think that you would probably better just use this kind of string 'V4 (preset medium)' and add '(fast mode)' globally at the end of TDescriptiveLameTagReader.GetPreset if vbr-mtrh was used.

LAME Tag Reader

Reply #43 –
Quote
*In any vbr Vx value, there can be a "fast mode"
I think that you would probably better just use this kind of string 'V4 (preset medium)' and add '(fast mode)' globally at the end of TDescriptiveLameTagReader.GetPreset if vbr-mtrh was used.

I tested "--preset portable" and "--preset fast portable" and got identical output files.  Neither used vbr-mtrh.  Same for radio.  What command line would I use to get fast mode for any Vx values other than those mapped to medium, standard and extreme?
 

LAME Tag Reader

Reply #44 –
Quote
I tested "--preset portable" and "--preset fast portable" and got identical output files. Neither used vbr-mtrh. Same for radio. What command line would I use to get fast mode for any Vx values other than those mapped to medium, standard and extreme?


Well, 3.94 alpha is under work. I commited yesterday low bitrate vbr-mtrh presets.

But soon, I will anihilate portable and streaming named presets, leaving only the -Vx equivalent of those.

LAME Tag Reader

Reply #45 –
OK, I will make the changes you have suggested for the next version.

LAME Tag Reader

Reply #46 –
Hi - i have a little suggestion:

When i test an MP3 encoded with Lame 3.90.2
LameTag.exe (v0.2.1b) reports the following for the version string:

Version string: 3.90.


Is there maybe any chance to get reported the hole version string
in future LameTag.exe versions?


However thanks for every work You do on LameTag!

384kbps

LAME Tag Reader

Reply #47 –
Quote
Hi - i have a little suggestion:

When i test an MP3 encoded with Lame 3.90.2
LameTag.exe (v0.2.1b) reports the following for the version string:

Version string: 3.90.


Is there maybe any chance to get reported the hole version string
in future LameTag.exe versions?


However thanks for every work You do on LameTag!

384kbps

C:\Download>LameTag.exe
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2003 phwip
Release 0.2.1 beta, compiled 2003-11-19

Usage: LameTag <filename>
      Wildcards and folders are not currently supported

Notes:
- The LAME version string in the LAME tag is only five characters
  long, so version numbers such as 3.93.1 are truncated.

LAME Tag Reader

Reply #48 –
Unfortunately this truncated value is all that is stored in the LAME Tag.  So it is not an issue with not retrieving all the information, simply that it is not there.

The same problem occurs with version strings such as "3.93.1" and "3.94a14" which are all truncated: you will see the same effect if you view the version string from the LAME tag in Encspot, Frontah or any other utility that reads it from there.  The LAME Tag spec only allows for 5 characters to be stored.

I think that some versions of LAME write a longer version string into other places in the mp3 file.  Frontah seems to read this, so there are cases where it shows the truncated version string on the "Lame Tag" tab, but shows a full string on the "File Info" tab.

LameTag.exe was only ever intended to read information from the LAME Tag.  I don't wish to get into reading information from other places within MP3 files.  There are other utilities such as Frontah and Encspot that do this much better and in greater depth than I ever could.

LAME Tag Reader

Reply #49 –
In versions prior to 3.90 LAME would store up to 20 bytes of version information, for example: "LAME3.80 (alpha 1)". With the introduction of the LAME header tag in 3.90 the version information was trucated to 9 bytes ("LAME3.80 ") which is unfortunately one or two bytes too short to store things like "LAME3.90.3" or "LAME3.94a14". So that's why LameTag (and getID3()) only return the truncated versions of the version string.

There is usually padding in the last frame in which LAME tries to write the longer version string, but there may or may not be room for the full version string, and it's not in any defined location. An aggressive program may scan for this version string at the end to find out if it's 3.90.2 or 3.90.3[/b] but that's not part of the specs.