When does it make sense to give tracks another track number then the sort order?

Please have a look at the disc 2 (Bonus Tracks) in this release:

the entered track # are not in the same order as the tracks itself:

I can’t imagine in which situation this could be useful.

Could please someone explain such a situation?

1 Like

Maybe it was the track ordering being wrong? This seems to be the same as this entry on discogs:

https://www.discogs.com/de/release/27382578-Lemon-Demon-Damn-Skippy

The track numbers match the numbers on the MB release. But on Discogs the tracks are sorted by the number, which also matches the listing on the cover images.

Or the order on disc actually is different from what is shown on the cover, but the original editor wanted the track numbers to match the titles as shown on the release booklet. Which would be odd and I don’t think I’d agree with such an approach.

1 Like

According to the mentioned cover image and listed track order:


it does not make really sense that - for example - track #4 “Elvis porn” appears at position #10 here at MusicBrainz.

Do I understand you correctly?

I asked the original editor.
https://musicbrainz.org/edit/100654316

3 Likes

I’ve seen a few bugs that get triggered on imports of data which causes a track list to end up shuffled like this. I expect it was one of those bugs.

If the CD you have plays in the same order as the track list on the cover then just correct the order on the tracklist page.

In this example I am pretty sure this is also the import bug. You can untangle it by looking at the AcoustIDs. You can see someone has submitted AcoustIDs in the correct order but assigned them to tracks with the wrong names.

2 Likes

The original editor has fixed CD 2. :+1:
https://musicbrainz.org/edit/112201206

3 Likes

Good to see fixed track list, but that has now left shuffled AcoustIDs. Lengths don’t match the tracks. I’ve gone through and deleted most of the AcoustIDs. These were easy to spot as they were the wrong length and the " Additional user-submitted metadata" didn’t match.

Better to delete the duff data and wait for a new AcoustID submission than risk the bad matches this would cause.

4 Likes

Yesterday I checked AcoustID for swap tracks 4 and 22 (iirc) and they were ok.
Which ones are wrong?

Look at the length of the AcoustID that was attached to track 04. It showed the swapped track 08 length. Track 04 Elvis Porn (3:41) => Track "0752c271-d3fb-43f9-8c03-a75d8c738d49" | AcoustID showed the AcoustID of Sky Blue Up (3:51). You can tell this by the length and the "additional user-submitted metadata” from another source also matched.

Check the track list and you’ll see the DiscID has set “Sky Blue Up” as 3:51 which would match that AcoustID.

All of the recordings that were moved in https://musicbrainz.org/edit/100654316 it could be seen followed this same pattern.

Only the tracks in the correct position on the track list had the correct length AcoustIDs attached.

Whoever it was who submitted the AcoustIDs had their tracks in the correct order, but submitted them to the album with the tracks named in the wrong order. So everything got offset.

(I have spent way too many hours studying AcoustIDs… :crazy_face:)

Track 22 did not have a problem as it is in the correct place in the order of the CD. Notice three tracks followed it both before and after the edit. So any AcoustID submitted was always correct. Correct length, correct Additional User-Submitted metadata

Yesterday the AcoustIDs were in the correct order, but the track names were in the wrong order. Which means AcoustIDs linked to the wrong recordings.

5 Likes

I looked at it this way but I missed it.
I’m always on smartphone, which is not very convenient.
Thank you for unlinking bad AcoustID!

@UNKNOWNGAM3r, could you please resubmit AcoustID with Picard, now that the tracks are in order?

3 Likes