rigth tag the first time.... but not the second !

[buzzybee]

Hello,

recently, I noticed that my librairy had many songs having the wrong tags. I decided to retag the whole thing…

Many songs were also added (a friend librairy), so that dup songs is now the rule. Total of maybe 5000 songs… with some 1000 dups.

I ran Jaikoz, starting right from scratch (erase all tags).

1- Maybe it’s just something with my settings, but I found out that Jaikox is actually having some trouble resolving with just the acoustic fingerprint…
Had to use MusicBrainz Picard to start the process.

Why is it like this ? Doesnt Jaikoz integrate everything that Picard can do? Is it this “clustering” phase in Picard that make it possible ???

Could something be done to get a “from scratch” tagging functionality ?

2- After this first phase, I got back to Jaikoz and ran everything again.
Oh surprise! Many songs had their title changed… that bugged me a bit, so decided to dig a bit…

So I found that two copies of the same song (just same title from same album… same acoustic ID… but not the same MP3!) could be tagged with two different titles !

What is still stranger is that I can start from scratch (ie no ID3 at all) with these two files (I validated with Picard…) and then

-hit the “retrieve acoustic ID” (note) button to retrieve the same fingerprint for both files

-hit the “autocorrect metadata from MB” (brain) button to retrieve the same and correct title for both files. Songs are identified as “Sister Golden Hair” from America (MB rec ID: f895cd05-47d7-4148-989e-8c8eb9596f04)

-without saving, hit the “autocorrect metadata from MB” (brain) button again, to now identify one of the file as “Company”, still from America (MB rec ID: 5c266405-6cbf-4860-8616-42b04d213846).

This final result is wrong… and any further command just keep these result stable…

I first thought this could be a problem with the file itself (corruption or something), but was also able to reproduce the same result by using two exact copy of the same file…

Could this be a problem with my settings, or something that could forbid two occurence of the same song in the same directory??

I will send the support file, and will attach the MP3 file.

Thank for your help !

[paultaylor]

Okay I have looked at your logs and think I can see what has happened. Firstly you must have Preferences:Musicbrainz:Automatch:Do not match online if have a Recording Id unchecked which is not the default, if it had been checked then your second attempt to Autocorrect from Musicbrainz would have done nothing because it would ignore all songs that already been matched.

As it is, the first time there is no metadata to match on and so each songs are matched individually purely on the acoustid fingerprint to the same song.

The second time you try and autocorrect both songs now have metadata such as artist name and album name. Because the songs have this information Jaikoz trys to group songs by the artist/album name and match the set of songs rather than matching them individually, this usually gives better results because the songs from one album are not broken up over similar but different albums.

So it checks the two songs against various releases which contain links to the song and in http://musicbrainz.org/release/ef3a7f90-0f36-4d60-928c-39d7947ce3fc it manages to match both of them to the release, it can’t match both to the same song because it was only exists once on the album but if you look at the http://acoustid.org/track/684ac92b-6ca7-4dc9-9700-7c01f7f710b1 page you can see at one point the acoustid also linked to a song called Company and as both Company and Sister Golden Hair are on the same release Jaikoz decides this could be the valid match.

Clearly wrong in this case, but an edge case.

[buzzybee]

Hum… ok, you cleared it up for this one!
This was some kind of AcousticID database “error”…

But if I recall, there was quite many songs for which this happened…
When I’ll get back into this, I will try to follow your path and make sure it’s the same kind of problem.

Just to better understand how this work, if this Company song had not been there, if it wasnt for this AcousticID database “error”, I guess it would then have been ok for Jaykoz to choose the same song twice, even if on the same album… is that it ?
(ouch… sorry if its bad english ! you understand what i mean ?)

One last thing: is there a way to force the matching to be done using the acousticID alone without first deleting every tags ?

Thanks for your help

[buzzybee]

…about this “one last thing”:

I know there’s no much point in deleting the tags if we take it for granted that they are right… But the situation came, before starting the whole retaging of my librairy, that many of them just had the wrong tags. (i have no idea why this happened!)

Thus, the idea is that it would be nice to know is if the tags still match the acousticID… (and then just correct those that dont)

[paultaylor]

I guess it would then have been ok for Jaykoz to choose the same song twice, even if on the same album… is that it ?

Yes, but autocorrect is multi-staged so it wouldn’t be allowed to match two songs to the same song when trying to match a group of songs to one release. But if that stage failed the later stage that just matches song by song with no regard to other songs would allow both songs to match to the same release.

Note normally when you have duplicate songs they are not in the same folder but in different folders so if you had

folder1/song1
folder1/song2
folder1/song3

folder2/song1
folder2/song2
folder2/song3

Then all the songs in folder1 could be matched to a release, and then all songs in folder2 could also be matched to the same release at the first stage.

One last thing: is there a way to force the matching to be done using the acousticID alone without first deleting every tags ?

To ensure acoustids are fully used I would run the Action/Remote Correct/Retrieve AcoustIds task before running Autocorrect , or even better add it to the list of Autocorrect tasks in Preferences:Manipulators:Autocorrecters. This ensures an acoustid is created for every song, otherwise Jaikoz only creates an acoustid when it feels it needs to because of a lack of a good metadata match.

However acoustid only matches a song to a recording, not a recording on an album so you don’t want to usually match to acoustid and completely ignore the metadata. But now the Acoustid database has matured i will revisit the algorithm to make sure when an acoustid does match a recording that we dont allow a metdata match to a completely different recoriding. Although this done run the risk of not allowing a match when two songs have a fingerprint that resolves to the same acoustid, but only one song (the wrong one) is known in the acoustid database.

Thanks for your help [/quote]

[paultaylor]

…about this “one last thing”:

I know there’s no much point in deleting the tags if we take it for granted that they are right… But the situation came, before starting the whole retaging of my librairy, that many of them just had the wrong tags. (i have no idea why this happened!)

If the tags are completely wrong you are right it would be useful to delete them as that will hinder matching by acoustid. But I dont think this is a common case metadata is normally roughly right but incomplete but not completely wrong.

I could add a function to make it easier to delete all the metadata from a song instead of having to select and then delete all fields. I could also add a matching option to ignore metdata when matching but then you have the problem of what album to match to.

[quote=buzzybee]
Thus, the idea is that it would be nice to know is if the tags still match the acousticID… (and then just correct those that dont)[/quote]
Even if the tags match the acoustid you still want to add extra fields such as the Musicbrainz Id, and the computing power required to chnage valuex to valuex is marginally different to not changing valuex