Read metadata to match MB releases

[nrosier]

My collection is completely ripped to flac and tagged with Picard. The metadata contains the albumartistid, albumid etc... so it would be easy to match up my collection to MB but I have a lot of unmanaged entries. Would it be possible to scan the files for metadata in use that information to match them. Same goes for different released. HP selects the wrong release even if the files contain metadata with the correct release.

[gasparhugoricardo]

I second that! I'd say this is the thing I miss the most. My library is completely tagged (also using Picard) and I have a huge amount of unmatched entries.

[achmetinternet]

+1, and it should compare AcoustID values beets can generate with those provided by MB. Is that possible?

[basilfx]

@nrosier @gasparhugoricardo: Headphones uses the MediaFile class to read metadata. If someone can provide example code to read the requested metadata, I am willing to look into this.

@achmetinternet: Please rephrase. I don't understand.

[achmetinternet]

I meant generating a fingerprint via beets and the Chroma/AcoustID plugin and then match it against the AcoustID in MB as a method to generate matches between tracks in your own database and MB.

http://beets.readthedocs.org/en/latest/plugins/chroma.html

[nrosier]

I don't have mediainfo; hopefully this information from metaflac can help:

metaflac --list 05\ Alors\ on\ danse\ (radio\ edit).flac | grep musicbrainz

comment[23]: musicbrainz_albumartistid=ab2528d9-719f-4261-8098-21849222a0f2
comment[24]: musicbrainz_albumid=019f547c-8d6b-4865-a2da-f73a4568c18b
comment[25]: musicbrainz_artistid=ab2528d9-719f-4261-8098-21849222a0f2
comment[26]: musicbrainz_releasegroupid=ce87cfa3-42cc-411b-b8bc-2d92aaa73c81
comment[27]: musicbrainz_trackid=0a6c5cce-044d-45ab-898d-b8a2c13f69f7

As you can see it contains all the information necessary to look up the correct release on MB.

[tocks53]

+1

[AdeHub]

More info here https://github.com/rembo10/headphones/issues/1005

[bounty1342]

@basilfx looks like the neccessary codes to read the metadate are already present on mediafile.py from the ligne 1721. I think the matcher should look first at realeaze with tags and they are presents store them in some way.

This feature would be a blast !

[papampi]

+1

[Enverex]

Amazed this isn't already implemented. Doing a search against Musicbrainz is infinitely more resource intensive than querying a release or artist by MBID.

[basilfx]

I looked into this and it isn't a straightforward fix. The info is available, but it is not something like overriding a few variables.

You are free to submit a Pull Request, though.

[tocks53]

basilfx, Can you explain what is problematic for this feature

[rembo10]

I haven't looked at the librarysync.py code in a while. This used to be one of the matching algorithms, but it looks like it was taken out, not sure why.... I'll look into adding it back in, because yeah, it's way easier

[tocks53]

Have you news of this feature? Thank you

[tocks53]

rembo, news about this ?

[rembo10]

Not right now but the code needs some major refactoring and this should definitely be included. I think it was matching on track ids at one point (but as a fallback as a track id can match to multiple releases) but if you have albumid & trackid it should definitely be used first

[hitnrun30]

I think I know the reason and have a simple answer but can't implement due to my lack of python knowledge. I think that this can be fixed from a database standpoint. I have become knowledgeable with the sqlite DB and I think the non matching is due to the CleanName. it not the same from the have table to the tracks table. if there is an apostrophe in have is will not have a space where in tracks there will be.

My suggestion would be to either set the cleanname in both places to have alphanumeric values and be upper or lower case. The other suggestion would be to use this when quering the cleanname upper(replace(CleanName,' ','')) This way there is no way it will have an issue.

[Andy2244]

I also have problems importing perfectly tagged musicbrainz releases. The problem is on a library scan it seem only names are used, instead of the already existing musicbrainz id tags. I tried to workaround this by using a custom post-process import, while adding the groupid's to the foldername. This kinda worked, but results in wrong releases being used, since the albumid is ignored.

[hitnrun30]

I found a slightly better workaround. I set the values of the names and tags, then afterwards rename the files if they have weird characters. But sometimes there are no substitutes like black star for David Bowie. Can't it just read the character and use it.

[Andy2244]

@hitnrun30 I have a lot of jpop and anime soundtracks, so "weird" names and letters are all over the place for my collection, including a lot of releases in kanji. Using the groupid "hack" works, but its strange that this only happens via pp and not on library scan. I really wish HP would use the MB albumid and ignore everything else on a import/pp, if those tags exist.

[achmetinternet]

Agree with Andy.

[monkiibiz]

@rembo10 any news on this? I see new issues being opened on this still.