SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Album matching

#1

I still get a lot of mixed up albums if I try and use autocorrect. Often manual correct fails as well - doesn’t offer the proper choice.

Some sugestions/requests to make this process a bit less cumbersome and time consuming:

  1. There is an update from unique track ID. The problem with this is that it is quite time consuming to paste in each individual track ID into the grid from a different webpage in MusicBrainz for each track. Add an action item to allow the Release ID to be used as the basis for a match - perhaps with the track number to ID the track. Then you would just have to paste in the release ID into the entire release column and hit the action item - a major time entry savings over the current method.

  2. If an entire release is being processed (or even if it is in the same folder?) use the number of tracks as a factor in the automatching logic. Probably the easiest things to get correct when ripping would be the number of tracks in the release and the track number of the track. As near as I can tell these criteria are not used in the matching logic.

  3. If “2” isn’t possible/pratical then how about using that information as criteria for the “Cluster Albums” logic? This action appears to be very unreliable now - ususally ending up with multiple releases selected for one group and often not the right one in any case.

  4. Ability to perform a “Cluster Albums” without having to have done an automatic/manual update first.

  5. Ability to have the “Cluster Albums” present a list of potential releases and allow the user to select the 1 that they prefer.

#2

[quote=dmw-01]1) There is an update from unique track ID. The problem with this is that it is quite time consuming to paste in each individual track ID into the grid from a different webpage in MusicBrainz for each track. Add an action item to allow the Release ID to be used as the basis for a match - perhaps with the track number to ID the track. Then you would just have to paste in the release ID into the entire release column and hit the action item - a major time entry savings over the current method.
[/quote]
I can see why this would be useful, I just need to get the terminology right because ‘Update from Unique track Id’ doesnt attempt to mtach the track it just updates the details for the track. Whereas you want to identify the Musicbrainz Id from the track no and release id , and then update the info so its more like ‘Autocorrect tags from Musicbrainz’ but using different criteria. Merging these options into tghe existing Autoccorect tags would give us a task that was probably too complicated so a seperate task called ‘Autocorrect tags from Musicbrainz Release Id and Track Id’ would work, but its a bit of a mouthful

Track number is used, no of tracks isnt because it isnt normally available. What you have to be aware of is that Jaikoz works file by file in the order the files are displayed, so a single release might not be grouped together.

Cluster Albums tries to minimize the number of Musicbrainz releases for the same release name. But I think there is a case for another Cluster Albums that minimizes how many release names releases are spread over in the first place.

Its work on Musicbrainz release Ids, so you have to update first. If it did the update itself that woukld be very confusing for the user, and how would it decide whthwer to do one or not , would it do an update if 50% of the tracks didnt have a MBid and 50% did ?

A ‘Manual Cluster Albums’ option, Ill consider it

#3

  1. Agreed, that is why I was thinking of it from the terms of “update” instead of auto-correct. I suppose that “Autocorrect from Release ID” would work pretty well. It would certainly get the concept accross, anyway. Additional documentation of what the criteria used with this could be in the help but I’d bet that most people would assume it was the track number if they stopped to consider it… Maybe just “Correct from Release ID” would be better since it is less “automatic”. Might distinguish it better from the regular Auto-Correct option, as well.

  2. In this mode, I’d do things an album at a time, I guess. I’d have to think that most people would tend to do entire albums solely so perhaps an option to add the number of tracks to the criteria would be a good idea, anyway - to cover the case when someone doesn’t rip the entire album, etc. If you wanted to handle the case where more than one album is being processed then how about: when you read the albums in from disk would it be possible to store a track count in a different linked table (in RAM, incremented with each read of a file in a folder) and then the total track number would be available no matter what was or wasn’t displayed? I suppose it wouldn’t have to be a different table - in that case you’d have to roll through the info just read after completing each directory and update a field. The biggest deviation from desired results that I’ve seen with the auto-correct functionality is getting the release with the correct number of tracks selected - there are usually several variations of an album released and the number of tracks seems to vary with each. Yes, there are often several with the same number but this would completely eliminate the ones that couldn’t be correct from consideration right away.

  3. As it is, it sometimes helps, but all too often it changes “good” ones to “bad” ones… Cluster might be another place to check for total number of tracks to make it a bit smarter in deciding which one to pick. Another possibility is to display the releases the tracks have and allow the user to pick which one to cluster on. Note: This last is a bit different than number 5 in that it only shows the ones that have previously been assigned to the tracks and doesn’t do any further analysis, etc. to find others.

  4. Actually, I’d have to say that it is very confusing now as it doesn’t do anything if you haven’t done the auto-correct. It took me a while to figure it out when I got this version. Now, the user has to highlight a block, select auto-correct, wait for it to finish, then select cluster. Simpler/easier to just select cluster and let it perform auto-correct automatically if it doesn’t have a release ID, etc. for the track. To answer your question if all but one of them had a release ID and I hit cluster then I’d expect it, on the one, to check the release ID(s) of the other selections that DID have one and see if which release matched best, etc. Use case - auto-correct the album, find the one that is correct, revert the others to saved (no release info.), cluster them to the one that was kept.

To summarize, the biggest amount of user time is spent getting an album together. The current logic, as you’ve stated, doesn’t consider the album as a whole and take advantage of that knowledge in it’s current thinking so it leaves a lot of debris to be cleaned up manually.

A follow-on request:
6) Not sure what to do about this but when you are attempting to work with multiple albums the autocorrect function tends to rename the album title and then you end up with albums scattered all over the place and they are difficult to find, etc. You have to unfilter and sort on changed and process an album at a time (at least that is the best way I’ve figured out how to do it, anyway). How about an option to sort/group/filter on the “saved” values instead of the proposed ones? That would keep things together a lot better while you are working on them. This is especially bad with unusual various artist compilation albums - they really tend to get scrambled now.

By the way, I think that this tool is fantastic. That is a bit of a curse, though, because the more you do the more people think of additional things for you to do… :slight_smile: THANKS!!!

#4

[quote=dmw-01]1) Maybe just “Correct from Release ID” would be better since it is less “automatic”. Might distinguish it better from the regular Auto-Correct option, as well.
[/quote]
In the context of Jaikoz:
Update mean update info for an already identified item
Correct mean automatically identify
Auto, mean do it without user intervention
Manual, means requires users to select from choices.
So sticking with Autocorrect

Most customers want to do process everything , they DONT right select a single album and work an album at a time. Youre track number logic is only going to work when you have all tracks , if one is missing or in a different folder the logic is going to prevent the valid match. I think if you are happy processing one album at a time why dont you just use manual tag from musicbrainz. Semi-automatic is probably a better term than manual as Jaikoz does the hard work for you - you just have to confirm/modify the matching track, and you can chnage the settings to process upto 500 records at a time, so you could use this method for processing a substantial set of albums in one go. Where there is a problem is that Jaikoz favours Puids over meta matches, and if the puid does not match the ‘correct’ release you are stuck, so i will add some way of preferring meta match over puid.

Cluster works on a the simple premise that it should use the release that most tracks are linked to, this seems reasonable, but we need to provide a few extra options in the initial Autocorrect to make it complelety configurable.

Talking as a user I hate applications that magically fix things,I prefer to make it clear whta the program is doing and let the user work out what they want to do. But I suppose i could add an option to Cluster Albums of ‘Autocorrect if doesnt have musicbrainz id’

Possibly, BTW have you enabled ‘Preferences/MusicBrainz/Match/Retrieve extended details for more accurate ratings’ this will slow matching a bit but shoudl keep your album tracks together better.

#5

I can’t figure out how to it does 2 levels of embedded responses so I’m leaving mine on top to hopefully avoid confusion.

  1. Don’t get me wrong, I’d love nothing better than ripping 20 CDs and turning it loose on them. Maybe its me (how I’m using it) or just the music I buy but when I do that things end up all over the place now. However, in this context, I meant that I would think that most people would tend to rip entire CDs, not that they wanted to process them one at a time. Sorry, my phrasing was a bit ambigious. As for actually processing one CD at a time in answer to your manual match question - it often doesn’t show me the correct one to pick from so it often is a multiple pass operation with manual match and and copying/pasting in IDs. Yes, I think that the proposal to be able to weigh the meta information more heavily might help this a lot.

  2. Yes, I’ve noticed that if I select 3 of the “correct” release and 1 other one it most often flips the other to the correct release. I’ve been using that a lot lately. There have been several cases, however, where, instead of changing the 1 to match the others it changes all of the others to match the 1. Should this be reported as a bug? If so, I’ll fully document the next one and report it in the issues area.

Yes, I have always had the “retrieve extended details” option turned on. I must have done that when I first installed it, I guess.

Thanks for listening and responding - it is greatly appreciated!

#6

[quote=dmw-01]2) … As for actually processing one CD at a time in answer to your manual match question - it often doesn’t show me the correct one to pick from so it often is a multiple pass operation with manual match and and copying/pasting in IDs. Yes, I think that the proposal to be able to weigh the meta information more heavily might help this a lot.
[/quote]
Manual Match shows the ten best matches (if 10 exist) so weighing the meta-info higher than the Puid isnt going to help if the correct match isnt listed in the ten choices anway. But under normal circumstances this is rare, maybe it is the track duration problem again - Your track length isnt within the range of the track length iof the track in MB, perhaps you could check.

Actually what I said before was inaccurate, instead it looks at all the release ids an album is spread over and for each release id it trys to match as many tracks as it can. Then it reallocates the matching tracks to the release with the most matches if it is different. If two releases both match the same number of tracks then it will use the release that was already matched with the most tracks.

Umm, I think some examples might help.

You have 9 tracks linked to releases as follows

Track 1 : release 1
Track 2 : release 1
Track 3 : release 1
Track 4 : release 1
Track 5 : release 1
Track 6 : release 2
Track 7 : release 2
Track 8 : release 2
Track 9 : release 2

5 tracks linked to release 1, and 4 linked to release 2. However when it trys to find matches its manages to match all of the 5 currently linked to release 1 to release 2, but only 3 of those linked to release 2 to release 1. So it changes the tracks to release 2 and we end up with

Track 1 : release 2
Track 2 : release 2
Track 3 : release 2
Track 4 : release 2
Track 5 : release 2
Track 6 : release 2
Track 7 : release 2
Track 8 : release 2
Track 9 : release 2

How would this happen in the real world - perhaps release 1 was the standard 8 track album, and release 2 was the same album with an extra track. The user has tghat extra track so jaikoz is right to match all to release 2 rater than release 1 because it could never match all tracks to release 1.

But it had only managed to match 4 of the 5 currently linked to release 1 to release 2, and 3 of those linked to release 2 to release 1. Both release 1 and 2 would be able to match 8 of the 9 tracks, so in this case it would favour release 1 because it had more matches to start with before clustering, and we could end up with

Track 1 : release 1
Track 2 : release 1
Track 3 : release 1
Track 4 : release 1
Track 5 : release 1
Track 6 : release 1
Track 7 : release 1
Track 8 : release 2
Track 9 : release 1

I’ll cover more than three releases another time.

#7

  1. Hmmm… It seems to happen a lot to me. I have the track duration weighted at zero so I don’t think that is it.

  2. Well, that also hasn’t always been my experience. I’ll pick 3 from what I think is the “correct” release and 1 that isn’t and do a “cluster”. They will all flip to the “wrong” release, sometimes. I then have to “revert to saved” (I now save after every good cluster operation to have a restore point) and skip that track. I’d say that most of the time it is due to something extra/missing on the track title.

Things like “(feat. Joe)”, etc. seem to make it not match at all. Come to think of it - this is probably why the auto/manual-correcting has issues as well. Not sure how to get around that, though, reduce the priority of text within “(” “)” characters?

The next one that I get that misbehaves I’ll document in more detail so I can explain/demonstrate it better.

#8

[quote=dmw-01]2) Hmmm… It seems to happen a lot to me. I have the track duration weighted at zero so I don’t think that is it.
[/quote]
Actually I think it is the problem because it is mandatory for the track length to be within track duration range of the track length in Musicbrainz. If you set the duration weighting to zero it wont affect the score but the track wont be returned as a possible matched in the first place, in the current version of Jaikoz the best thing you can do is set the duration in the ‘MusicBrainz/Match’ tab to be at the maximum 9 second range. This came up in this post http://www.jthink.net/jaikozforum/posts/list/15/357.page

I am going to make track duration match non-mandatory although by default it will be enabled because it really helps against completley invalid matches.

I would like an example , but certainly if your track has ‘Track 1(feat. Joe)’ in the title but the release just has the track as ‘Track 1’ then it wont match because it does exact title match which should be fine because if you have already updated the track from MB it would have replaced ‘Track 1(feat. Joe)’ with ‘Track 1’ . Or if MB has ‘Track 1’ on one version of the release and ‘Track 1(feat Joe)’ on another version of the release then MB is wrong and Jaikoz doesnt stand much chance. And remember cluster only works on tracks that have been matched on MB.

#9

Oh, I see. Thanks for the tip on the track length setting.

On the track title the problem it is apparently a bit more complicated - often, now, there seems to be several releases of the same album: limited, special, bonus, remaster, anniversary, UK, Japan, Germany, US, etc., other, … They all have slightly different song titles and song order. Also, bonus tracks, remixes, acoustic versions also make things more complicated. Then add in abbreviations… All of these variations are in MusicBrainz and seem to match the actual album. The best way that I’ve been able to manually determine which release is the correct one is by checking the number of tracks that the release has and comparing it to what mine has. Then looking at song order (using primarily the main part of the track title) if several have the same total number.

#10

I second this request. This would be very helpful. Maybe allow you to select which track in a release to use for each file.
So you would:
Select the files in an album

Identify the Release ID (maybe from a list of Release ID’s in the above selection)

Jaikoz would attempt to match track to file.

You would be presented with a window similar to the Manual Correct Tags window where you would confirm the selections (but only tracks from that release are available).

Another way to do it would be the ability to lock the Manual Correct Tags window to a specific Release ID.
So you would:
Run Manually Correct Tags on a group of files (all in the same album).

You don’t like the results, so in the Manually Correct Tags window you select the release ID you want.

Manual Correct is rerun with track in that release only.

Maybe add a feature to temporarily “juice” the match score while in the Manually Correct Tags window as well.
So if I don’t like the results, but I know the track numbers are all correct, I could click the track number column and the Manual Correct algorithm will be re-run with the track number factor bumped up.

That should give dmw the functionality he wants without adding a convoluted menu item. And it allows flexibility to use the feature in other ways while only adding a couple of button presses from dmw.

-oillio

BTW- the latest BETA is great. Matches a few more correctly. And I can now use manual correct on many more of the incorrect matches.
If I could get the above feature Jaikoz would do everything I need.```