How to assign a recording to a track?

Tags: #<Tag:0x00007f7d009816e0> #<Tag:0x00007f7d00981618> #<Tag:0x00007f7d00981488> #<Tag:0x00007f7d00981348>

(long topic opener, I know… couldn’t help it :face_with_hand_over_mouth:)

Looking at this decision:

Screen Shot 2020-08-19 at 21.51.14
From the documentation:

if you’re sure that the recording is the same as one already in the database (see the recording guidelines), you should press “Edit” and search for it.

I added this digital media release of “The Best Of The Bar Kays”, and because the album was first released in 1992, I based the tracklist on the 1992 CD release (it has the same barcode).

This means I assigned the same recordings to the digital media tracks that someboedy else had assigned (or created) for an earlier CD release.

I didn’t think much about that. But then I noticed that there are three recordings of track 4, Sang and Dance (I own that song from the iTunes Store) – this, this, and this.

This made me think -

Should I assign a different recording to track 4?
Should I create entirely new recordings for all tracks just to avoid being incorrect (easiest solution)?

Should the three recordings of Sang and Dance be merged?
Should a work entity be created?
How to clarify which recording existed first?

The duration differences are surely negligible (silence). But why not get an objective assessment of the differences, using AcoustID? With other words, can AcoustID be used to help with the decision whether two recordings are similar enough to consider them identical?

I see that the fingerprint generated with Picard for my Sang and Dance file got assigned to an AcoustID that is actually found on all three recording entities. I think that is a good indication that:

  • the recordings can be safely merged
  • it doesn’t matter which of the 3 recordings is assigned to track 4 - all of them are correct
  • the decision which recording to assign to a track is easier AFTER having submitted a fingerprint

Maybe there is an idea here for a new function in Picard (@outsidecontext) that checks whether the AcoustID submitted for an audio file matches the AcoustID of the recording currently assigned to a track. If yes, that strengthens/confirms the association between track and recording. If not, then another AcoustID will be added to the recording. At this point, the user could be alerted to the fact that his/her file is different somehow. This can mean three things:

  • the difference is negligible (duration or mastering differences)
  • the recording is a different version and should not be assigned to this track
  • the recording currently associated with the track should be removed from it

I mean, currently, becoming aware of these things is left to serendipity.
If we could trigger checks that employ AcoustID, it could help with

  • selecting the correct recording to assign to a track
  • speeding up the comparison between multiple recordings of one song

(just exploring - let me know how you approach linking recordings to tracks and what you think about the idea of making more use of AcoustID)

3 Likes

– and then you have songs like Stand by Me with a trillion recording entities by Ben E. King, some of which don’t even have an AcoustID. That is where a programmatic approach to “cleaning up” might help human editors.

From the documentation:

Recordings of different durations can be merged, as long as there is no evidence to suggest that differences in mixing or editing have caused the change in lengths.

How to create the “evidence”? Could we let a program run over all these recordings, compare the AcoustIDs and identify the outliers?

All three recordings have the same main fingerprint aka AcoustID. So, it appears that they are all indeed the same recording and should be merged. Vinyl timings aren’t nearly as accurate as digital so it’s not uncommon to see times that vary within about 7 seconds, sometimes a little more. It’s just a difference in the mastering process. Yep, behind adding releases, merging is probably the second most activity on MB. Check acoustIDs & ISRCs to verify recordings that should be merged.

2 Likes

This the way I look for needed merges:

  1. Look for shared ISRCs
  2. Check for shared acoustIDs.
  3. From the same release group.

If you can’t get this data, I wouldn’t merge them yet. https://isrcsearch.ifpi.org/#!/search is a good source to check against barcodes & ISRCs. Even better, for Digital releases is Spotify using the a-tisket site:
https://etc.marlonob.info/atisket/

4 Likes

A different opinion (from someone who spends pretty much 0 time merging recordings…), I always think acoustID is pretty useless for something specific like trying to match specific recordings. Much too easy for people to submit to the wrong release, and no vetting process.

That said in this case, where it doesn’t look like there were any re-recordings of this track, I would just merge them. It just looks like they recorded one single/album and then the track was used in some compilations. Not the slightest sign of a re-recorded version, for instance as a bonus track or something (just a remaster).

5 Likes

Yes, acoustIDs are only valid within 7 seconds of the duration of the recording. There are way too many that shouldn’t be, so you must double check each timing to make sure they were supposed to be attached correctly. I’m mainly talking about shared acoustIDs that are close in time with each other and have good sources. Don’t just merge every release with the same acoustID without checking each recording or you will get bad merges.

1 Like