New Music Tag Reader -- Testers needed (1 Viewer)

[mbuzina]

Hi!

First of all: Very cool scanning, it scanned 1200 Files in 41 sec (according to counter)!

It scanned all data correctly (incl. German Umlauts).

There is one issue: If the Year Tag is empty, it shows up as 0, which is probably an issue converting from int? to int on null values.

<edit> Forgot to say: Scanned only mp3 (I have nothing else).

 

[SteveV]

New version posted (see first post for link)

Changes:

Fix missing genre when using custom genres
Fix embedded coverart being read incorrectly in MP3 causing silent exception and missing coverart
Fix "0" being displayed for year when Year tag field is empty
Added verion info string to status bar

TODO:

Add logging
Fix WMA problems (still waiting for user feedback!)

 

[knutinh]

I am asking here because it seems the most relevant place. I will do further testing when I get home this evening.

But how big a jump is it from being able to read every tag from every concievable format, to being able to write every tag? I know that there are many programs that do this, but most dont do it right, and those that do costs $ =)

I sort of envision a program that searches the music folder intelligently, making a database of every file where full path name, "neighbor" files, filename and tag info etc is stored for every file. Then the user kicks back and opens a can of beer while the program:
-searches for duplicates (file length, name, etc etc)
-use every string connected to the file to do a "most likely" freedb search
-keep all tagging data allready present
-tries to "connect" single files into albums
-tries to format artist name coherently, and automagically move music files into folders sorted by artist and album name
-after an album has been uniquely identified, a textfile with the unique CDID is placed next to the file, meaning that it will be identifiable for all future.
-after all this processing presents the user with (hopefully) a few files where it cant make any choice, and ask the user to identify them.

regards
knut

 

[SteveV]

I am asking here because it seems the most relevant place. I will do further testing when I get home this evening.

But how big a jump is it from being able to read every tag from every concievable format, to being able to write every tag? I know that there are many programs that do this, but most dont do it right, and those that do costs $ =)

It's a big jump but one we'll eventually make. And as you've already indicated, most tag writers are responsible for a lot of crap in the files. However, as in all things MP when we do it it'll be done right and it'll be free .

I sort of envision a program that searches the music folder intelligently, making a database of every file where full path name, "neighbor" files, filename and tag info etc is stored for every file. Then the user kicks back and opens a can of beer while the program:
-searches for duplicates (file length, name, etc etc)
-use every string connected to the file to do a "most likely" freedb search
-keep all tagging data allready present
-tries to "connect" single files into albums
-tries to format artist name coherently, and automagically move music files into folders sorted by artist and album name
-after an album has been uniquely identified, a textfile with the unique CDID is placed next to the file, meaning that it will be identifiable for all future.
-after all this processing presents the user with (hopefully) a few files where it cant make any choice, and ask the user to identify them.

regards
knut

Obviously a much bigger jump but an interesting idea.

1. searches for duplicates (file length, name, etc etc)
should be easy to do if the tagging is accurate

2. use every string connected to the file to do a "most likely" freedb search
I'm not sure how well freedb handles searches based on title, artist, album, etc. I seem to recall it does them poorly

3. keep all tagging data allready present
No problem

3. tries to "connect" single files into albums
MP's share scanning/database update does this now although with some difficulty if the user's music collection is poorly organized.

4. tries to format artist name coherently, and automagically move music files into folders sorted by artist and album name
Not sure what you mean about the formatting aspect but moving files into the appropriate folder is dependant on 3 so we'd need to come up with a much more robust method to "connect" tracks to albums

5. after an album has been uniquely identified, a textfile with the unique CDID is placed next to the file, meaning that it will be identifiable for all future.
I'm not sure if you can generate a CDID from tracks that have already been ripped from a cd. I beleive the CDID is generated from the CD's TOC along with individual track duration.

6. after all this processing presents the user with (hopefully) a few files where it cant make any choice, and ask the user to identify them.
Assuming 5 *were* possible tracks that were incorrectly read would be missing from an "album" which would make getting the CDID impossible. So even missing as little as 5% of the tracks would result in a lot of user intervention.

Nonetheless an interesting idea with potential

 

[onkl]

Just a very short remark:

[...]
5. after an album has been uniquely identified, a textfile with the unique CDID is placed next to the file, meaning that it will be identifiable for all future.
I'm not sure if you can generate a CDID from tracks that have already been ripped from a cd. I beleive the CDID is generated from the CD's TOC along with individual track duration.

Maybe you can't generate them, but you can download them from freedb.org. Think of it as a reverse query.

 

[SteveV]

Just a very short remark:

[...]
5. after an album has been uniquely identified, a textfile with the unique CDID is placed next to the file, meaning that it will be identifiable for all future.
I'm not sure if you can generate a CDID from tracks that have already been ripped from a cd. I beleive the CDID is generated from the CD's TOC along with individual track duration.

Maybe you can't generate them, but you can download them from freedb.org. Think of it as a reverse query.

True, but this gets us back to a text based freedb search.

[EDIT]
Try a text search on "beatles abbey road mean mr. mustard"

Returns 18 hits and 7 DiscID's. Granted that this is the web interface. The API may return something more usable.

Steve

 

[knutinh]

I have spent countless hours tagging my own music, and I do know that finding the right logical "ID" is difficult even for a human interested in music, even more so for a dumb computer =)

Part of the problem is that cddb and freedb have errors and inconsistencies. The same album may exist with several different text entries (upper/lower case variations etc).

And the music on peoples harddrives may be anything from:
Madonna\track1.mp3
Madonna\track2.mp3
...

To fully tagged, fully organised music. And even tagged music may be inconsistent or miss important tags.


I do believe that the "quality" of freedb is better than typical mp3s, so the problem should be reduced to finding the most likely candidate(s) from this database from the available information.

Problem with many taggers is that they dont separate "99.99% certain" from "50% certain", so the user have no choice but to wade through endless amounts of files and check if the info suggested by the tagger is sensible. I would like a system that weights the quality of the match, then give me the worst matches first. Having standard clickable windows forms mean that I can sort on artist, "certainty parameter" etc.

An option to auto-format fields would be nice. Such as formatting all trings in artist with leading capitals and stripping underscore. This is also nice to apply on freedb to decrease the number of possible variants of one artist spelling.

In the end, converting a large collection of messy mp3s to a usable searchable collection will always be a lot of labor, and I think the goal should be making it as simpl as possible, not automating it fully.

regards
knut

 

[knutinh]

Running v 0.21 of the test app now, I had one crash where the app vanished completely when I tried to run it on all of my music

Now testing sub-folders one at a time. and I have had 3/3 sucessful. It seems tha some wma as well as mp3 files return "error reading tag"

I removed the folder containing crashing material, and now the reader reads all my remaining files without crashing.

Some fields that are marked as empty in windows (right-clicking) is filled with weird ascii letters


-k.

 

[SteveV]

Running v 0.21 of the test app now, I had one crash where the app vanished completely when I tried to run it on all of my music

Now testing sub-folders one at a time. and I have had 3/3 sucessful. It seems tha some wma as well as mp3 files return "error reading tag"

I hope to add logging in the next day or so which should make finding the file where the error occurs much easier. So don't kill yourself trying to find the specific file.

Thanks,

Steve

 

[GoldenEye]

SteveV

I don't know whether this is the right place to post this - but at least it's related. I have two questions:

- Do you plan to read additional tags from the files - the one I am missing the most is the composer tag, which is crucial for ordering classical music.
- Do you plan to support more than one artist by song - e.g. "Ray Charles, Norah Jones" so that they appear as two separate songs in the database?

Thx a lot

G.