(long topic opener, I know… couldn’t help it )
Looking at this decision:
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)