MusicBrainz NGS + AcoustId Tagger [MM3&4] v1.25 2012-01-29

[booblers]

However disabling the Title field still updated capitalization on Title field when saving.

I remember now why I made this a toggle way back when. It's because of one of the many *infuriating* aspects of MM. Let me explain:

The built in "SmartUpdateTracks" method (lol) accepts a simple array of titles. The order that MM displays the results in the window at the bottom is dictated by the order of this array. The matcher uses this given array to attempt to match old data to new data - this is why it's so bad when titles are similar but other metadata is completely different. Since the matcher is far from "smart" and is actually quite dumb it also does us the favor of assuming that we want to change the title to whatever we've given it in the array (as opposed to matching based on the title and then also allowing us to turn on titles if we desire).

So if you want to keep the old title you have 2 options. You can feed the "SmartUpdateTracks" method the old title to match on. Ok - well, now you've accomplished nothing since it's going to match each track to itself. The other option is to feed SmartUpdateTracks the array of "new" titles to match on so it can actually do something but then it forces the change on the title. Now what you can do is go back and overwrite the title with the "old" data - and this will work in certain scenarios where the number of tracks all line up and the matcher understands everything - so that the indexes in the array you fed it match up with whatever the result will be at the bottom. No problem in those scenarios. But - when they do not? Problems.

Now I can avoid using the dumb smartupdatetracks matcher and using the other matcher you will always be fine - but then as soon as you disable munkres you can get erratic behavior. I'm not sure what to do there... I will think about it. I may just disable the smartupdatetracks way of doing things and force Munkres..like I said... thinking about it

[MMuser2011]

However disabling the Title field still updated capitalization on Title field when saving.

Do we already have a Bugtracker-Ticket to change/adjust this behaviour?

[booblers]

It's not that simple. What would need to happen is a complete re-write of the smartupdatetracks method to work in a way similar to my matcher.

Or if not that - at least it should be the case that what is returned from the smartupdatetracks method is a hash of the indexes of original data -> new data that it thinks are appropriate. Then it is left to the scripter to designate the order in the results window and the data that appears there.

Of course they won't do that because it would break every other script out there. I will find a way around it. I've given up on asking MM developers to do anything. Even if you get a response the result will most likely be another myopic half-fix that doesn't get the job done (as it appears it will be with their proposed version of custom tagging and etc which is why I gave up and just did it myself).

As it stands now we know one index but have to "guess" or "infer" the other which can lead to undesirable behavior. This is why, for example, the original version of this script would always get the Track# wrong if the titles were the same. He was inferring that if OldTitle=NewTitle that OldTrack#=NewTrack# and thus he would assign everything else based on the titles being equal - that's all the method allows him. This is fixable if you use a custom matcher (like the Munkres) and do it all yourself which is probably the answer here. So annoying.

[MMuser2011]

Only a rough idea:
What about a standalone script, which could run AFTER all the tagging work?
Now - with the help of the embedded MusicBrainzIDs or AcoutIDs - it should be much faster to call this track/album on the MB website again and get the "right" capitalization from the Source.
(Or is there any other - private - capitalization which Lowlander refers?)

What about the filename? Could such a script rewrite the filename according to a renaming scheme like <Track##>/<TotalTrack##> - <Title><Extension>

I don't have coding skills, its just an idea.

[booblers]

Yes. He prefers not to let scripts modify his titles - that is the problem (Musicbrainz is providing proper titles - he must have some idiosyncratic preference). He wants to keep his titles in tact but the SmartUpdateTracks method will demand that they be modified if you feed it anything *except* the original titles. Going back to the original titles after calling SmartUpdateTracks with new titles would require that the titles be the same (or so similar that they are trivial to compare - it would help if one knew *exactly* how SmartUpdateTracks works - I'm not holding my breath there either).

One can avoid calling SmartUpdateTracks alltogether but then the order of the tracks as they appear in the results window is not intuitive (it's the order that NewTracks come from ISDBWebSearch::NewTracks - this is either alpha order or ID order - I don't care which as both are terrible.

After some thought the only solution I see is to just keep Munkres on (as I always do anyway). Then we can feed the SmartUpdateTracks the old titles (effectively making it do nothing) so the titles aren't modified and then let the better matcher do the work.

[booblers]

Let me know if the latest link works better. Title checkbox should work - this makes Munkres essentially mandatory and I should remove the checkboxes associated with it at some point when I'm sure it will work for most people.

I added the "artist" relationships for a given "work" at Musicbrainz along with a checkbox. These will be stored in OriginalLyricist and that tag choice cannot be changed. These are not just original lyricist (since that specific formulation is rarely available) - instead they will be the same type of credits that appear in Involved People for a given track but these will be people involved in the "work" behind the track. Writer, Arranger, etc. If this is undesirable let me know.

As a result you can no longer choose to put Lyricist into "Original Lyricist" - at some point I will remove that select box in the settings as well (when I'm sure people like it this way).

Lowlander: Where is your preferred place to store "Performers." This is an advanced relationship for a given recording that is available. The previous version of this script added any "Performers" to artists. I find this undesirable as I prefer only artists credited on the track to appear in artists. Do you use this information and if so where would you want it stored? Currently it isn't being saved.

I'm still looking at your cover art situation MMuser. Most of my covers are 1500+ square. These would be too large to display in the results window. Would you be happy with a resized version? That is essentially what you have available in MM already when you highlight the tracks to select them for tagging... so I'm not sure how much good that does you.

[MMuser2011]

...I'm still looking at your cover art situation MMuser. Most of my covers are 1500+ square. These would be too large to display in the results window. Would you be happy with a resized version? That is essentially what you have available in MM already when you highlight the tracks to select them for tagging... so I'm not sure how much good that does you.

The same/similar preview size as in MM is pretty nice! Or even the same preview size as the one from MB.
I save cover art with a size of 500x500 inside my tracks (after resize the too big one)

[MMuser2011]

I: Idea for faster AcoustID speed:
Is it possible to let the fingerprinting process generate the ID's at the same time for several tracks in different threads?
(Now it seems, that track after track will be processed. I'm wrong?)



Q: No AcousticID if MusicBrainz ID are already stored in track?
Is this correct: If your script can find a Musicbrainz-ID inside a track, it doesn't create the additional AcoustID?

[booblers]

I: Idea for faster AcoustID speed:
Is it possible to let the fingerprinting process generate the ID's at the same time for several tracks in different threads?
(Now it seems, that track after track will be processed. I'm wrong?)

You are not wrong - it is, in principle, possible to speed this up for people with multiple cores. It is CPU intensive as it is decoding the entire track and then running another algorithm on top of that. So I'm sure you're maxing a core as it is. I will think about it adding it.

Q: No AcousticID if MusicBrainz ID are already stored in track?
Is this correct: If your script can find a Musicbrainz-ID inside a track, it doesn't create the additional AcoustID?

That is correct. If the script finds existing MBIDS it uses those. It is, after all, a MusicBrainz tagger. I will probably write a standalone AcoustId tagger that will run separately in the background on entire libraries or on selected tracks much like the Generate PUID script from Trix currently does. Probably soonish but I'd like to make sure this is working well first.

I've added an option to display the first image in the first selected song in results (500x500 with a line telling you the actual size). There is a disk penalty here again as the file must be taken from wherever it is (in case it's in a tag) and written to the temp folder and then displayed from there in the html. I've noticed a slowdown on search results (and I use a very fast SSD HD). Up to you. It's also pretty dumb about what it displays - like I said - the first image in the first file (as reported by MM). It will update to use another track if you change "seed song" but I don't expect many people to do that. It's still not clear to me that this is a great benefit as you are seeing the artwork already if you are selecting the tracks in MM... but there you go. It'll be uploaded with a new link in a few mins.

[booblers]

I uploaded a new version MMuser that you should check out. The case you sent me was an interesting one. The string_distance calculation is using what is called the Levenshtein distance algorithm. Part of this algorithm is the notion that any add, delete, or replace operation counts in the distance. In your case you had much simpler tags than MB was offering up to tag them against. So what was happening was that the length of the tags you had were so little that a large number of "add" operations were counting against them - then the engine wanted to try to cut down on those operations by matching short tags to short tags rather than relying on similarity. In addition there were no duration tags for those files in MusicBrainz *and* the track numbers were off. Basically all that was the same was a tiny fragment of text. Enough for a human to recognize intuitively but difficult for the algorithm.

You probably don't care about any of that. A 2nd test is now performed when a low-confidence result is found with Levenshtein. It will take a bit of time if it fails as it's now doing a Longest Common Substring match as well. That should take care of most intuitive cases. I haven't tested it as much as the other so let me know if you find odd behavior. There were some other fixes as well relating to the calculated album order string and other nonsense. Let me know how it works.

Oh - I should also note that you should change your thresholds back to normalish values if you kept them where they were earlier etc. And even with this new SubString calculation in place you will only get a Low or maybe up to Medium confidence because *all* the other information is still incorrect. But you should at least be able to tag it after seeing it is actually correct etc.

[MMuser2011]

The newest one works great. I already found dozens of albums, thanks to your script!
Best matches returning for full albums (correct number of tracks).

I have one little wish:
Could you please add a keyboard shortcut to your Script?
I'm not sure if this could help: http://www.mediamonkey.com/wiki/index.p ... nstall.vbs

Thanks again for your great work and this wonderful script!

[booblers]

There is already a default shortcut for auto-tagging scripts: CTRL-L

This will pull up the MM auto tagger with the last selected autotagging script....

[MMuser2011]

CTRL-L
-> with the last selected autotagging script....

Ahh, thats why! Thank you!

[scratchie77]

Hello there,

Awesome script, really really useful.
My question is can i sort the results of the search by year (earliest to most recent) as i am trying to get the original release dates of songs for my collection.
I dont have many original albums in my tags because i sort them into "Songs From 2009", "John Mellancamp - My Selections", "Songs From the 80s" etc
At present i have to manually select the earliest release date from the results (and hope the earliest release is in the results to start with)

Thanks in advance
Glen

[booblers]

The short answer is: no, but maybe in the future.

The list of results that is returned depends on a lot of things. There are different types of searches that the script can make (you can see the list in a results window where it says "Search Entrance"). The search is progressive and will start with the first in the list and if it finds a match it will present that to you as the only release available from MB.

This means that if, for instance, you have embedded MB Album ID tags in the first file (or in the seed song file if you enter the search manually) that only 1 release will be returned - the release corresponding to the MBID in the tags. This is desired behavior in my view as once you put those tags in a file you shouldn't have to guess which release it is. You can override the decision to show you just that one release with the dropdown mentioned above.

Other searches limit things in other ways - so for instance if "enforce track-count" is on and there are available results that match the # of selected songs you have then you will NOT see the releases that don't match the # you have selected.

So: when you say "hope the earliest release is in the results" my thought is that if the earliest release isn't in the results then either MB doesn't have the earliest release in the database - or - the searcher has found a match while enforcing some criteria to limit results. But if it has done that then it is very likely that the release you are tagging isn't the "earliest release." So if you've downloaded, I don't know, some deluxe version with extra tracks that was released 2 years later than the original and you try to tag the deluxe version the script is very likely going to only show you results for the later deluxe version (because, that's what you have!)

Some features can be overridden with options - you can turn off track count and etc. But some other things related to string matching can't be turned off.

With respect to sorting: adding a sort order for the results should be possible and I will look into it but that functionality will break in the future when I make this version work more like my version (and more like beets). Currently it is just showing the top result as reported by MusicBrainz - but every release could go through the same matching algorithm to determine the best candidate and pre-select that one.