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

LAME Tag Reader

Reply #50 –
Very interesting information...
I didn't know what the 20 chars in maximum did change to 9 in newer Lame version
so that there only would be left the 5 chars for the version number of the encoder.

Nevertheless it's a pitty to have those truncated encoder version numbers 


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

Yes, i have seen that sometimes - mostly if the frame quality is 32kbps - there
is the complete encoder name in the first or last frame of the MP3.
Unfortunately exaclty these frames are in danger to be cutted/overwritten
by 'shortening' or maybe even re-gain tools.


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

That's ok. Please keep it as fast as it is!
Scanning a hole MP3 in the holy wish to find one of the above mentioned
'identification frames' takes quite long and the success is insecure.



But... Would it be a stupid idea to rename encoder identification name/string
inside the Lame encoder executables from "Lame3.90.2" (one char too much)
in "Lame3.902" (length = 9) ?
This even would work on "Lame3.93.1" - however, me too i don't how to solve
the problem at names like "Lame3.94a14" ... 


384kbps

LAME Tag Reader

Reply #52 –
Quote
LameTagGUI v0.1.0 is now available as a front-end for phwip's LameTag.
Nothing really fancy, just adds a directory tree view and a mouse interface.

http://www.silisoftware.com/applets/LameTagGUI

this is exactly the kind of nice, light-weight and most importantly SMALL program i have wanted

can we expect drag&drop, and recursive scans of directories soon? if so, i would just scrap EncSpot from my system.

LAME Tag Reader

Reply #53 –
http://www.silisoftware.com/applets/LameTagGUI
v0.1.1 is now drag-&-drop enabled (sortof, couldn't figure how to update tree view to reflect dragged file's location - anyone is welcome to fix it if they can).

@aron: What do you mean by "recursive directory scanning"? LameTag is designed to analyze only one file at a time 

edit: now v0.1.2 due to some bugfixes

LAME Tag Reader

Reply #54 –
Quote
http://www.silisoftware.com/applets/LameTagGUI
v0.1.1 is now drag-&-drop enabled (sortof, couldn't figure how to update tree view to reflect dragged file's location - anyone is welcome to fix it if they can).

@aron: What do you mean by "recursive directory scanning"? LameTag is designed to analyze only one file at a time 

edit: now v0.1.2 due to some bugfixes

yikes! the new one is full of bugs!

-it is supposedly 0.1.3, but it still says 0.1.2 in the titlebar

-it does not clear the info of previously scanned files, but appends to the window instead, making it very difficult to see the new info

-the follow-path-of-drag-n-drop-item feature is nice, but in some cases it slows it down. now, it needs to spend extra time scanning the directory tree structure. in the case that i drag an item in F:\ (this directory contains MANY, MANY folders), it now takes 5 seconds or so before i can get a reading)

-when using this new follow-path feature, it showed directories that i had already moved! when i double clicked them, it said 'directory does not exist'


where can i get another copy of 0.1.2? i would like to downgrade for now, but i didn't save my older zip. do these bug reports help? i can test more, if necessary.

LAME Tag Reader

Reply #55 –
v0.1.2 (last version by me) is now available at the same location.

LAME Tag Reader

Reply #56 –
Quote
v0.1.2 (last version by me) is now available at the same location.

Thanks for the GUI, really makes it a bit easier

LAME Tag Reader

Reply #57 –
Quote
v0.1.2 (last version by me) is now available at the same location.

thanks, getid3

LAME Tag Reader

Reply #58 –
Quote
yikes! the new one is full of bugs!

Hmm... Yes, this does seem to be the case.  Unfortunately not only the ones you mentioned.  I am aware of two others:
  • Open a folder and then close it again very quickly by clicking twice on the + button.  This is wrongly interpreted as a double-click and launches LameTag.exe.

  • Drag & Drop onto the bottom half of the screen works correctly, but drag and drop onto the treeview incorrectly causes a file copy or move operation to the folder onto which the file is dropped.
These, especially the second one are fairly serious, so I would recommend for now that everybody sticks with 0.1.2 until I create a new version that fixes these bugs.

Now onto the specific issues you mentioned, aron:

Quote
-it is supposedly 0.1.3, but it still says 0.1.2 in the titlebar

When I made this version and sent it to GetID3() it was just to show him how using a different treeview component could solve a couple of problems.  I expected that he would include this change if he wanted and continue development, but didn't at that point expect him to release it as 0.1.3.  So it didn't occur to me to change the version number.

Quote
-it does not clear the info of previously scanned files, but appends to the window instead, making it very difficult to see the new info

This will be easy to fix, so I will do so for the next release.

Quote
-the follow-path-of-drag-n-drop-item feature is nice, but in some cases it slows it down. now, it needs to spend extra time scanning the directory tree structure. in the case that i drag an item in F:\ (this directory contains MANY, MANY folders), it now takes 5 seconds or so before i can get a reading)

I can't at the moment think of a way round this one.  The only other app I can think of that has similar functionality (drag & drop resulting in moving in the tree to the dropped file) is EncSpot and this suffers from exactly the same speed problem in this situation.  Really it is not so much a bug as just an unfortunate side-effect of the added functionality.  So the only way probably I can get round this is to make that functionality optional.  In your case, as you find this annoying, you would be able to switch this off, so that dropping a file would have no effect on the tree view.

Quote
-when using this new follow-path feature, it showed directories that i had already moved! when i double clicked them, it said 'directory does not exist'

This is very strange: I get almost the opposite.  With the original version 0.1.2 if a folder is visible in the tree and then that folder is moved (using Windows Explorer) it remains in the tree and clicking  on the + button next to that folder generates the error message "This folder was moved or removed."  With the new version when the folder is moved the treeview in LameTagGUI is automatically updated within less than a second.  So there is no error message.  So in my case the bug (or one very like it) is present in the older version and fixed in the new one.

Would you please check this to make sure which version you saw this in?  Can anybody else confirm this bug?  Please make sure you are dropping the file on the lower half of the LameTagGUI window, not the treeview, otherwise it may be that the problem you are seeing is simply a side-effect of the bug mentioned above where dropping on the treeview causes a file move operation.

Quote
do these bug reports help? i can test more, if necessary.

Of course they help.  It is always useful to hear of any problems so I can try and fix them.

LAME Tag Reader

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

Since the SW upgrade seemingly all the uploads are lost too. So would you be kind enough to upload the this nice command line utility and its source?

Many thanks.

LAME Tag Reader

Reply #61 –
Version 0.3.0 of the LameTag.exe command line program is now available on GetID3()'s website at http://www.silisoftware.com/applets/LameTag

The largest change is that it now includes preset guessing for lame tags where the preset field is blank (ie. all versions between 3.90 and 3.92 except for later 3.90.3).  Thanks to GetID3() for giving me the idea for this and providing a lot of valuable information along the way.

It also can now scan multiple files if you use wildcards in the filename (or give it a folder name instead of a filename), and can scan recursively through all subfolders if you use the --recursive switch.

It will also now correctly interpret the new fixed point replaygain track peak values created by lame since 3.94beta, and will cope with pre 3.90 files that have a lame header but no tag.

I have removed all the uploads from this thread.  They weren't working anymore since the forum upgrade, and they aren't needed anyway now that GetID3() is hosting the files.  I would be grateful if a moderator would move this thread from Uploads into a more appropriate forum such as General - MP3.

LAME Tag Reader

Reply #62 –
Quote
Version 0.3.0 of the LameTag.exe command line program is now available on GetID3()'s website at http://www.silisoftware.com/applets/LameTag

The largest change is that it now includes preset guessing for lame tags where the preset field is blank.....

very nice update, thank you phwip.
the preset guessing is something i've been (sort of) doing on my own for a while. ("quality 78, nssafejoint yes, nspsytune yes.... vbr old / vbr rh.... probably standard or extreme!")

...but it is nice to have this feature in the program now

as for the handling of multiple files, maybe we could see a modified LameTagGUI v0.1.2 soon. that would be wonderful.

anyhow, thanks again for the continued work. i use your tool constantly.

LAME Tag Reader

Reply #63 –
Unfortunately I discovered a bug in yesterday's version (0.3.0) of the LameTag.exe command line program.  When it reads multiple files (eg. by using wildcards or a folder name) the ReplayGain and Preset information is only displayed for the first file.

I have created a new version 0.3.1 that fixes this bug which you will find at the usual place: http://www.silisoftware.com/applets/LameTag

LAME Tag Reader

Reply #64 –
it would be nice if your little app could calculate the actual Music-CRC as well. I know that AI can do that, but somehow I doesn't work the way it should...
--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'