I ripped my CD of The Soft Boys - A Can of Bees many years ago. Picard tagged it with the data of the day. Unaware at the time that RecordingIDs of tracks 7 and 13 were wrong. Incorrectly swapped.
This week that data online was corrected. This meant tracks 7 and 13 SWAPPED online. The Recording IDs have been swapped around into the correct order.
Now I go to retag my CD rip. I uploaded into Picard and expected track 7 to go into track 7, and track 13 to go into track 13. But EEK! Nope. They SWAPPED and followed their now incorrect RecordingIDs to the wrong slots.
Not really what I expected. I expected Picard to load track 7 as track 7 and update that incorrect RecordingID.
My only way to fix is to manually drag and drop and swap the files.
Now the puzzle. What if I had not been aware of the online changes? Picard will just swap my track 7 and 13.
Puzzle made stranger as both tracks have the same name.
Expected behaviour: stick to track number order and update the now incorrect RecordingIDs.
This happened to me at first, then I dragged the tracks back to their newly corrected spots and saved. Now if I refresh, both recordings end up at position #13:
Relevant lines from the debug log, but they don’t seem particularly enlightening:
D: 09:24:58,556 file.move:615: Moving <MP3File “07 Sandra’s Having Her Brain Out.mp3”> from <Track 811ab98c-6c68-4ae8-8458-b256ee5bbb6a “Sandra’s Having Her Brain Out”> to <Track d914af57-70ef-4b48-9b82-0de488f4cb36 “Sandra’s Having Her Brain Out”>
D: 09:24:58,586 file.move:615: Moving <MP3File “13 Sandra’s Having Her Brain Out.mp3”> from <Track d914af57-70ef-4b48-9b82-0de488f4cb36 “Sandra’s Having Her Brain Out”> to <Track d914af57-70ef-4b48-9b82-0de488f4cb36 “Sandra’s Having Her Brain Out”>
I wonder if the now-unlinked acoustid is still being referenced somehow.
Yes, as the MBID identifies a recording exactly this is used as an identifier to match to the proper track. Picard can’t really know that you tagged the file against the wrong MBID before.
What if you had originally noticed the swap and tagged your files against the correct MBID? Would you still expect Picard to change it now to the incorrect one? The situation would present exactly the same to Picard.
Or asked otherwise: On swapped files, how could Picard tell if the track no. tag or MBID + title tag are wrong?
And how is Picard supposed to know, that’s what was wrong? Could have been the correct recording in the wrong position. If you know about the issue, you could “clear existing tags” (if that’s possible)
I think you miss what I did. I tagged it correctly the first time. The TrackID would confirm this. The ReleaseID, TrackID, TrackNo, TrackName, etc have not changed.
Now the associated RecordingID has changed, Picard has seen that as more important that the TrackID.
The TrackID has stayed the same. So have the track numbers and all other details.
This would work in this case as I did know about the situation as I was involved in the edit. But I am more thinking about any one else who now retags this album as is not aware that the data in MB has changed. They will now have their tracks incorrectly swapped.
To me it is more logical that TrackID is checked above RecordingID. That is less likely to ever change.
If the AcoustID was being referenced the tracks would have stayed in the orginal order. (Actually - not so sure about that… but I was not doing a scan here)
Until just recently both recordings had a mix of acoustids. The acoustid I referenced was linked to both, but I unlinked it from the longer recording on the 12th.
Sorry - brain is a bit frazzelled. Yeah, the AcoustIDs would previously been mixed up. But your work cleaning this up should have helped keep my tracks in the Correct as listed order if I did a Scan to link these as the AcoustID matches my ripped track order now.
I expected that MBTrackID to take precedence as that is what is static within this Release. CDs are made up of Tracks. The only data that changed online was the MBRecordingID
(Ignore the new green data in the image. Been a few years since I updated the tags. And the track title is only yellow because I change Unicode ’ to ASCII ')
(This is supposed to be a constructive “why did that happen?” post. I am not trying to be critical. I realise I am really rubbish at expressing what I am trying to say. Picard is brilliant. Just to be clear. I am just spotting a rare edge case. )
Now I see, so it was not really the track order changes but the recording link, right? So yes, in theory we could probably match by track ID first.
Not fully sure though if we wouldn’t get the other problem. I think this is a bit special case, because you had basically the same song, just slightly different recordings. So for you it was basically all tagged right, just the recording changes. While from Picard’s point of view the recording was right, but the track changed.
Now the more common case I have seen several times is that two different songs are switched because e.g. the back cover tracklist was printed wrongly. So in such a case e.g. track 7 and 13 would have been referencing different songs, and those had been swapped around. Now if there is a disc ID you can’t move tracks, you’d still change recordings for existing tracks so they reference the correct song. If you had tagged your files before but had been careful to match the proper audio to the correct track, then you actually would expect the files to change track number on re-tagging after the release has been fixed.
Yep, now you got it. The USA CD and UK CDs have a different order for tracks 7 and 13. Different length recordings swapped. @highstrung corrected the error that was on the UK CD in the database which means swapping these two recordings around.
Only after @highstrung repaired the database did Picard rearrange my Ripped Track order. As I don’t let Picard rename files this stood out as slightly comical on the hard disk as I could see “07 - The Soft Boys - Sandra’s Having Her Brain Out.flac” had changed its Track No tag to 13. The lengths let me also confirm this.
If Picard had renamed the files too then the Ripped CD would have been permanently broken and only fixable if I spotted the error or manually wiped out the tags and started again with a SCAN.
I’ve sent you a linky to the zip file of the “before” files in case you want them to play with. I pulled them from a backup when I spotted this happen.
Oh - and “basically the same song” is misleading here. This would still have happened if it was two differently named songs. And I have seen that occur on a Release before.
With your other example of Tracks named wrong on a track list - you would still want to keep them in TRACK order. When you rip your CD you’d have the tracks correct in the correct order. Initially the typed order in the database would name them wrong. Picard would name the tracks as per the database. If someone renames then in the database and swaps the names around, the TRACKID would stay the same. Picard would now correctly rename the tracks.
In normal cases that is what should have happened here. Just by chance the two tracks that have been swapped share the same name. If instead they were called Sandra’s Brain and Ivan’s Brain, and Highstrung had corrected the track list at the same time, Picard would still have made a muddle of the CD ordering by following RecordingID instead of TrackID.
Not if you tagged the files against the proper recordings in the first place. Which would e.g. happen if you use AcoustID, or if you manually assign the files manually. I had such cases, and I definitely would not have wanted Picard to change the tagging against the proper songs just to satisfy the track no. The point is that if you have wrong metadata how do you decide which is wrong? E.g. if track no. and track ID say one thing, and title + recording ID something else.
At that time the AcoustID was “correct”. It was matched in the database as the error had been around long enough for the two recordings to have each others AcoustIDs attached. That is another thing @highstrung cleaned up. This was the “proper recordings” according to the database in 2017
Only since this week has the database been correct.
When I tagged these it was in my very early days of using Picard. Now I would have noticed the length differences and investigated, but not back then. I just assumed the database was correct.
The CD was ripped in the correct order. It was tagged using Picard data that was correct at the time.
Today when I reload it Picard now swaps the Track Order of the files as it is ignoring the database that is it reading. It is presented with an album with correct track ID, MBTrackIDs still correct. Instead it assumed MBRecordingID is the thing that is never wrong.
Today when that old ripped album is loaded into Picard you have to be really sharp eyed to spot there is a problem that needs manually fixing.
I sent you a copy of the CD as ripped to have a play with.
Would you also have wanted Picard to switch the recordings if you had originally tagged your files the other way around to the proper recording? Again I think this case is special, because you have twice the same song. But let’s imagine this were originally two totally different songs, track 7 was “Sandra Having Her Brain Out” and track 13 was “Sam Having His Brain In”. At least this is how it is on the CDs track list, but in reality both tracks are switched on the pressed CD. Both would be different songs, with different title and totally different music.
Now you tag your files against this release. There are two ways this turns out:
You just match the files to the release in track order, hence tagging the recording of “Sam Having His Brain In” as “Sandra Having Her Brain Out” and vice versa.
You actually tagged the files against the proper recording, so you tagged your file for “Sam Having His Brain In” as track 13, even though on the CD it is on position 7.
Now things get fixed by renaming the two tracks and swapping the linked recordings. In case 2, would you still want your recording of “Sam Having His Brain In” stay on position 13 and change to the recording “Sandra Having Her Brain Out”?
I wipe my tags and feed these files to Picard - I get one result. The correct result. CD tracks still in order as ripped.
I keep 2017 tags and feed these files to Picard - I get a different result. A result that has swapped two files around. Now the ripped files are not in CD track order.
I drag the files back to the left, Cluster and Scan them - now I am back to the Correct Result.
I guess the real answer is I should always wipe all tags each time? Or do a quick rescan?
The important thing is the inconsistency does stand out in the colouring.
-=-=-
If I had manually over-ridden the database that would have been a little odd. Would it not have been the more logical situation there that I would have done as @highstrung did and go in and correct the database?
In my case if I do manually over-ride the database I set Read Only flags and leave a note to tell myself to check again carefully due to previous errors.
“twice the same song” is only hiding that the issue is there and harder to spot.
I do follow your example, but I guess I am different as I try and keep things in the order of my actual CD rips. If I don’t like the data in the database and don’t want to correct it, then I’d manually edit my files. If I had known I had manually corrected them, then I would not be surprised if Picard at a later time tried to correct that correction if it had corrected data to work with.
(Sorry - this seems to be getting more intense that I meant it to. It is just a puzzle to me that in some cases the data can cause Picard to reorder the CD as ripped )
Why? Maybe you don’t even notice. If the actual recordings had correct AcoustID and you used that to find matches the tracks would just end up on the correct recording. Or you had already the proper titles on the ripped files, and looking up with Picard hence matched it to the proper recording. Maybe you’d notice that the files are now in different order than they are on CD, maybe not. But if you listen to them they have the correct title.
The two cases are described above basically present as the same to Picard. You have track number + track ID telling one thing, and title + recording ID telling something different. How to decide which is wrong and which is correct? Really is it the track number tag that is always correct?
Actually if you have additional relationships on the recordings, with performer and writer credits etc., and things like first release date the majority of the tag data would support the recording case.
And I’d argue that with sufficiently different tracks (not just a variation of the same recording with same title, but two clearly different songs) the second case is more common, as it is more likely that proper AcoustIDs are available or people notice the difference when listening.
Or here is a sample puzzle to solve: You have the following file, which claims to be from the A Can of Bees release discussed above with this metadata:
I think one criteria to solve the dilemma above would be to also consider track length. If track MBID + length match the file, use the track ID for matching the file, if recording ID + length match better than use this. It wouldn’t probably help much in the above example I’ve chosen (track 2 and 3 have nearly the same length), but in many other cases it would.
UPDATE: I added this ticket:
UPDATE 2022-02-17: @IvanDobsky So we merged a change that makes Picard match either by track ID or recording ID by considering also the track length. In my tests this works really well. Your example files would yield the result you expected. And if you would have tagged the two tracks the other way around (tagging against correct recording instead of correct track position) it would also now swap them around. So I’m quite confident that we can actually satisfy both situations.
I can still think of theoretical cases where this does not work. E.g. same track length on the swapped tracks, or file’s track length not accurate enough (as it can happen with pure AAC or AC3 files where the length gets estimated by bitrate). But then either approach can give right or wrong results and we are in the above situation where it is basically impossible to decide.
Brilliant. Thank you for looking at this. I realise it is a weird case. But I am weird and I find weird issues. I like the elegant sound of your fix. Looking forward to the next release.
The USA CD and UK CDs have a different order for tracks 7 and 13. Different length recordings swapped. 
I like the elegant sound of your fix. Looking forward to the next release.