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 40837 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME Tag Reader

I have created LameTag.exe, a little command line application that displays the values from the LAME tag for an mp3 file.  The first beta version, 0.1.0, is attached.

This was inspired by John33's new compile of LAME 3.90.3 that now writes the preset used into a field in the LAME tag (see this thread).  Encspot doesn't show this field when it displays the LAME tag, so I wrote this to provide a way it can be viewed.

This is my first attempt at programming anything to do with audio files so it may have its faults.  Please feel free to pass on any comments or bug reports via this thread.

Hope you like it.

EDIT: now hosted at http://phwip.wordpress.com

LAME Tag Reader

Reply #1 –
just tested it, works flawlessly on win xp.

thanks, man

LAME Tag Reader

Reply #2 –
would you share the sourcecode? i would compile or port it to linux if possible.

BadHorsie

LAME Tag Reader

Reply #3 –
Works fine here too!!  Also WinXP Pro SP1.

LAME Tag Reader

Reply #4 –
 

I'm quite happy to share the source code but it's Delphi (5), so I guess the only way to port it would be to use Kylix.  I don't know much about that or whether it would transfer easily.  Anyway I will attach it to this message.

Also I have used a class and another routine from the open source Project Jedi JCL.  Don't know if that will complicate things more.  The routine (TestBit) is a one liner so I that could just be copied across.  The class (TJCLFileVersionInfo) is simply used to get the Title information (description, version, compile date, etc.) from the version info resource.

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

LAME Tag Reader

Reply #5 –
thanks so far. i never touched delphi sources before but i'm shure i can destroy anything 

BadHorsie

LAME Tag Reader

Reply #6 –
Seems to work fine.
You might want to also display the ReplayGain value (stored by Lame 3.94)

LAME Tag Reader

Reply #7 –
Quote
Seems to work fine.
You might want to also display the ReplayGain value (stored by Lame 3.94)

is LAME 3.94 already out yet? 
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

LAME Tag Reader

Reply #8 –
Quote
Quote
Seems to work fine.
You might want to also display the ReplayGain value (stored by Lame 3.94)

is LAME 3.94 already out yet? 

Only as an alpha.

LAME Tag Reader

Reply #9 –
Quote
Quote

is LAME 3.94 already out yet? 

Only as an alpha.

Will there ever be a final version......................................no (guess) 

(Please don't react on this post. Only ignore it.)

LAME Tag Reader

Reply #10 –
Quote
Seems to work fine.
You might want to also display the ReplayGain value (stored by Lame 3.94)

No problem.  I only left it out because I didn't think it was used by any implementation of ReplayGain for mp3 (the only ones I am aware of being MP3Gain and Foobar2000, both of which store values in APEv2 tags AFAIK).  And I wanted to save time.  I haven't used Lame 3.94 so didn't realise the field was stored in that case.  I will try and create a new release in the next week or so.

Should I also include the MP3Gain field from the LAME tag?  This doesn't seem to be used by the current implementation of MP3Gain, and I thought it might be confusing if people had MP3Gained their files and then the LAME tag reader displayed this value as zero.

LAME Tag Reader

Reply #11 –
Quote
Should I also include the MP3Gain field from the LAME tag? This doesn't seem to be used by the current implementation of MP3Gain, and I thought it might be confusing if people had MP3Gained their files and then the LAME tag reader displayed this value as zero.


Don't know. Perhaps you could display it with the value "not filed" instead of "0"

LAME Tag Reader

Reply #12 –
Here's the second beta release: 0.2.0, which includes the ReplayGain and MP3Gain fields from the LAME tag.  This means that now all of the information that is stored in the tag is displayed.

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

LAME Tag Reader

Reply #13 –
Here is the source for release 0.2.0 beta.

As well as adding in reading of the ReplayGain and MP3Gain fields I have made major changes to the structure of the code.  This is because I wrote 0.1.0 in a bit of a rush, without expecting anybody would want to see the code, and quite frankly it was a bit of a mess.  The changes should make it much easier to read.

I have separated out the code into three areas.  The first (BasicLameTagReader.pas) handles reading the file and returning the basic field values.  The second (DescriptiveLameTagReader.pas) handles formatting the field values for display including converting internal enumerators to descriptions.  The third (LameTag.dpr) contains the code for the command line application.

Although the code has been largely restructured, behind the scenes it is doing the same as before.  However, if you are interested in using this code I would strongly recommend you use this version instead the old one.  Also, if you do want to make use of this code in any way I would appreciate if you would let me know: just add a reply to this thread.  Thanks.

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

LAME Tag Reader

Reply #14 –
@gabriel:

EDIT: removed my questions, I answered them to myself.


@phwip:
great work

LAME Tag Reader

Reply #15 –
rarewares website.
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

LAME Tag Reader

Reply #16 –
ok, checked the lame alpha 14 on rarewares:
This is my result for lame alpha 14 --alt-preset standard -Y

LameTag - Reads the LAME tag from an mp3 file
Copyright © 2003 phwip
Release 0.2.0 beta, compiled 2003-10-06

Quality:            57 (V4 and q3)
Version string:    3.94a
Tag revision:      0
Encoding method:    vbr old / vbr rh
Lowpass:            19.000Hz
Replay Gain PSA:    <not stored>
RG track gain:      -13.5dB (determined automatic
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:          4
Bitrate:            <unknown>
Encoder delay:      576 samples
Padded at end:      1.284 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:    <none>
Preset:            standard
Surround info:      none
Music length:      7.037.204 bytes
Music CRC:          B8D8
Info tag CRC:      2E75

LAME Tag Reader

Reply #17 –
now I really got interested.

now that lame obviously can calculate RG values and has a proper MP3gain tag.
are there any switches to MP3gain my music?

LAME Tag Reader

Reply #18 –
No, I don't think so.  From the LAME Tag specs about the MP3Gain field:
Quote
only tools like mp3gain should use this field, as it is made for making lossless adjustments to the mp3 after encoding is finished.  No need to support this in LAME or any decoder at all.

LAME Tag Reader

Reply #19 –
Cooool tool - This like X-Mas in November !
It even runs on my simple php featured web server ;=)
(well, C/C++ is too difficult to me...)

Thank You very much! - I often use tools like Mp3Trim or EncSpot.
Due to any suspicious but 'functional' MP3 header manipulation,
(=> http://www.hydrogenaudio.org/forums/index....showtopic=14974 )
often the Lame tag wasn't readable any longer after cutting off
some frames - till now !

Thx again & please keep this project alive!
  384kbps

LAME Tag Reader

Reply #21 –
Quote
This could be useful to expand another open source project

Anybody is free to use the source code in any other project they wish.  Unfortunately I don't know VB well enough to translate the code to it.  The LAME Tag specs are simple enough and documented well enough that I would imagine it would be easier for somebody to rewrite this from scratch in VB than translate, unless somebody happens to know both VB and Delphi very well.

Quote
Thx again & please keep this project alive!

Glad you are finding it useful.  I am happy to make changes if any are needed.  But I can't see anything else that would need doing: all information in the LAME Tag is being displayed.  And I can't imagine the LAME Tag spec is likely to change.

LAME Tag Reader

Reply #22 –
Quote
I am happy to make changes if any are needed.  But I can't see anything else that would need doing: all information in the LAME Tag is being displayed.  And I can't imagine the LAME Tag spec is likely to change.

Quote
It's not --nogap or any other useless hack like that, LAME 3.90 and above stores gapless playback info in LAME tag by default. Most of files encoded with recent LAME you possibly have will play gaplessly without any crossfade / guessing amount of silent samples / etc.

Can this be reported?

LAME Tag Reader

Reply #23 –
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.

LAME Tag Reader

Reply #24 –
Quote
Quote
It's not --nogap or any other useless hack like that, LAME 3.90 and above stores gapless playback info in LAME tag by default. Most of files encoded with recent LAME you possibly have will play gaplessly without any crossfade / guessing amount of silent samples / etc.

Can this be reported?

I am presuming (but may be wrong about this) that the gapless playback info mentioned here is referring to the two encoder delay values which are already reported by LameTag.exe as "Encoder delay" and "Padded at end".