Issue Details (XML | Word | Printable)

Key: MBS-2513
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Oliver Charles
Reporter: Aurélien Mino
Votes: 29
Watchers: 13
Operations

If you were logged in you would be able to see more operations.
MusicBrainz Server

Allow updating recording information when track information changes via the release editor

Created: 03/Jun/11 09:55 PM   Updated: 09/Jan/12 02:09 PM  Due: 19/Feb/12   Resolved: 09/Jan/12 02:09 PM
Component/s: User interface
Affects Version/s: None
Fix Version/s: Schema change, 2012-01-12

Issue Links:
Relates
Resolution
 


 Description  « Hide

Having the ability to have distinct titles between track and recording is a nice feature.
However in at least 90% of cases, this is not needed.

So when a release is entered with typos, or capitalization issues, you have to:
1. edit the release fixing N tracks
2. edit N recordings

This is not painful, that clearly I've given up doing 2.
We need a solution for that.



Sort Order: Ascending order - Click to sort in descending order
voiceinsideyou added a comment - 04/Jun/11 02:04 AM

What do you think of nikki's suggestion at MBS-2021, Aurélien?


Aurélien Mino added a comment - 04/Jun/11 07:36 AM

I agree with MBS-2021 (I've voted for it a long time ago), but it only solves the track/recording length part.
I'm mainly talking here about title and also artist credit.


voiceinsideyou added a comment - 05/Jun/11 04:59 PM

Ahh, sorry. I keep misreading "titles" as "times" on this one!


Per Starbäck added a comment - 06/Jun/11 11:52 AM

I would prefer it if recordings usually didn't have their own titles, but inherited them. When presenting a recording use the most common title of its tracks. Only as an exception you'd set the recording title explicitly for a recording there are tracks for, when you know this is the right title, but there are lots of bogus/strange tracktitles.

Technically either there would be a special value (empty string?) denoting unset session title, or, if it's unfeasible to recompute most common title each time, cache that value in the recording title field, and have an extra bit stating that this recording title isn't set explicitly.


Aurélien Mino added a comment - 06/Jun/11 12:16 PM

Per Starbäck: What you're proposing is in total opposition to the style principle stating that track title is what appears on the cover while the recording title is standardized.


Per Starbäck added a comment - 06/Jun/11 01:01 PM

Aurélien Mino: That's certainly not what I mean. I'll try to be clearer:

What you have when you enter data is often a release. Then you can be certain of the tracktitle. For example I have a compilation cd "Hits of 1930" with a track "Confessin' (That I Love You)" with Guy Lombardo:

http://musicbrainz.org/recording/d1faeff2-5470-469d-9f1c-0cc8f9caff66

That song ( http://en.wikipedia.org/wiki/Confessin%27 ) is sometimes called "Confessin'", sometimes "I'm Confessin' That I Love You", sometimes "I'm Confessin'" etc. There are three tracks in Musicbrainz where Lombardo performs this song. They are separate recordings now and the other two are

http://musicbrainz.org/recording/303242ea-5202-424b-9244-06061cb2300e
http://musicbrainz.org/recording/965b3c90-5b21-477c-9194-0eb549ed4004

I think they really are the same recording though. Let's assume I'm correct about this. But what is the correct recording title? All of these three have (slightly) different titles! If you were to merge them, then you'd have to decide which title to use for the recording. I guess the best answer is the title used on the original 78 release from the 1930s ("normalized"). That's not as easy to determine for most users.

With my suggestion you wouldn't have to do that. With this example my suggested majority rule wouldn't do much since all alternatives are as common, but when later another track is added maybe there will be two of the same, and the situation will become better without anyone doing anything special about it. And if later real Lombardo buffs go in an edit the recording with detailed info, they might now (and set) the "real" title explicitly.

P.S. Hey, shouldn't that be Confessin' etc, with RIGHT SINGLE QUOTATION MARK, and not with the ascii '? Yes, so these tracktitles should be edited, and with my suggestion the recording title would just follow suit automatically.


Oliver Charles added a comment - 30/Jun/11 11:36 AM

Until there is a clear solution, I can't work on this


Benji99 added a comment - 01/Jul/11 07:04 PM

Personally, I'd be very happy with this:
When you edit a recording, to the right of the edits (there is currently a lot of white space) you could dynamically make a list of tracks where the recording appears. We could then check which tracks we want to to changes to also apply to. By default it should probably not have any tracks checked.

We would then just get into a habit of editing the recording rather than the track list...

In fact I'd also love to have this also for works where to the right you'd see a list of recordings and further to the right you would see the tracks. This would be immensely useful for classical music! where we could concentrate on cleaning up the works list and be able to apply the changes right up the chain.

What do you think?


Václav Brožík added a comment - 05/Jul/11 11:22 PM

@Benji99
Be aware of the fact that a list of recordings of a work can be very long (hundreds of items) see for example: http://musicbrainz.org/work/8596e5aa-85e1-4f76-907f-ea02aee39ea3

BTW there should be something similar for "part of" works. The correct implementation should be that a part of a work (symphony movement) would not contain name of the work (symphony) it would contain only a join phrase and name of the part (movement number, movement tempo). Similar mechanism should be for aliases of the "part of" work. Did you see an issue for this here?


Robert Kaye added a comment - 22/Aug/11 09:24 PM

Voice: Can you please think about this a little and see what we should do about it?


voiceinsideyou added a comment - 24/Aug/11 04:54 PM

Gosh. I wish I were Mister UI and the solution instantly came to mind I will certainly try, but probably won't have time to think until this weekend. I haven't even thought through the above suggestions properly! Have the above been considered and rejected/maybe-d or anything?


Jim DeLaHunt added a comment - 03/Oct/11 09:59 AM

I just encountered this problem. I was fixing up the track list for recording of Mozart's opera Don Giovanni (http://musicbrainz.org/release/24320d30-8603-402a-a937-a2469e9c4b00) which has 71 tracks over 3 CD's. Perhaps what I should have been doing is fixing up the recording name list.

Some steps which would make this situation better for me:

1. If there is an official style principle that "track title is what appears on the cover while the recording title is standardized", as Aurélien Mino says, then document it better.
1.a. http://wiki.musicbrainz.org/Track_Title should mention this principle.
1.b. http://wiki.musicbrainz.org/Style/Recording (which refers to http://wiki.musicbrainz.org/Style/Titles) should mention this principle.
1.c. The Release Editor's Tracklist tab should say "enter the track titles as they appear on the release packaging. (Standardised titles belong on the Recording.)" or something like that. i.e. document at point of use.

2. Make tools for bulk changes to sets of related Recordings. When I want to fix up the metadata for a Release I own, I start with the Advanced tracklist of the Release Editor. That's because it gives me all 71 tracks of all 3 CD's of my "Don Giovanni" in one table.
2.a. Extend the Recordings tab of the Release Editor to update Recording names based on the current Track names. This is appropriate when the current Track is the only reference to the Recording, and the Track name is standard enough to use as a Recording name.
2.b. Extend the Recordings tab of the Release Editor to provide text edit fields for the names of all the Recordings at once. Right now it only lets you search for an existing Recording, IIRC. When you have 71 related recordings which share common prefix text (e.g. "Il dissoluto punito, ossia il Don Giovanni, K. 527:") it's very helpful to have the whole set of names editable, so you can copy and paste between them.
2.c. Maybe when Works are better linked to Recordings, it might make sense to have a tool to apply the Work name to all Recordings that include that Work. But I think that as of September 2011 we don't have the Works infrastructure fleshed out enough to make that worthwhile.


Jim DeLaHunt added a comment - 04/Oct/11 12:50 AM

Aurélien Mino, you cite "the style principle stating that track title is what appears on the cover while the recording title is standardized."

Has such a principle been officially adopted? In the mb-style thread, "Recording/track distinctions " (June 2011), http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Recording-track-distinctions-td6605546.html , Lukáš Lalinský says,

"I'm personally unhappy with the NGS style guideline changes that
increase the differences between track titles and recording titles.
This is generally about the trend to have "as-on-cover" data in track
titles.... this version of NGS was never intended to have such
significant distinctions between recording and track titles. Track
titles were meant to represent recording title variations in the
context of the release. The same style guidelines would apply to both
titles, recording title just being just the most commonly used track
title."

Also, as I read http://wiki.musicbrainz.org/Style/Titles , I don't see any mention of "as on the cover", or different rules for Track Titles vs Recording Titles.

I see value in storing "as on cover" titles somewhere, but I don't see where the MB Style guidelines have a principle for it today.


voiceinsideyou added a comment - 04/Oct/11 02:01 AM

No, that principle was overturned as the outcome of RFC-333 which stemmed from luks' thread. Aurelien's post was prior to this, and was the prevailing orthodoxy. His post was well before the outcome of that debate and reflected truth at that time.


Oliver Charles added a comment - 18/Nov/11 06:03 PM

As this is blocked for the current iteration, I'm moving it to "Upcoming versions." We need to converge on a solution here soon!


Oliver Charles added a comment - 28/Dec/11 11:57 AM

Ok, we need some sort of solution to this in just over a month, so we need put our thinking hats on! First, lets summarize what options we currently have.

Recordings inherit track data

In this solution, recordings are created with nothing but an MBID, and they "inherit" data from tracks. How this inheritance works is yet to be decided, but I personally think using the modal data (most occuring) is a good first stab.

Open problems:

  • What do we do about our existing recordings?
  • How does this affect our customers? Will customers have to spend effort to determine a recordings title?

Allow propagating edits to recordings

When a track is edited, present the user with the option to also edit the recording too.

I think this are the 2 main options, and I'm leaning towards the latter solution. I suggest we decide which of these we want to work with by next Friday, and then spend a week after that on mockups. If I don't hear any feedback, I will assume the second solution as correct.


Paul Taylor added a comment - 28/Dec/11 12:16 PM

+1 for second solution, I think we have to go this way if Ive understood the 1st solution correctly, that is that recordings no longer have an independent title. But wrt the 2nd option want I want is to say set the recording title and/or length to that of the track im editing, I dont want to manually re-enter that data

Here is one possible solution, add two checkboxes working on the tracklist tab

Use Track Time as Recording Time
Use Track Title as Recording Title

and another checkbox per track that was enabled by default

this would apply to all tracks on the release, if you wanted to just wanted to propagate chnages to some tracks, you would uncheck the per checkbox track for ones you didnt want to change.


patate12 added a comment - 28/Dec/11 12:17 PM

Just a quick thought on « modal data = most occurring ».
I think it's « modal data = most occurring in official releases ».


Oliver Charles added a comment - 28/Dec/11 12:41 PM

Paul: with the first solution, recordings do have an independent title, but only if someone explicitly sets it. Otherwise, it will use the most frequently occuring title (or some other heuristic).


Paul Taylor added a comment - 28/Dec/11 12:56 PM

Thanks for the clarification, SO with option 1 when you first create that recording as part of the creation of the first track assuming you dont enter a different recording title to the track title the recording will have the same title as the first track whatever heuristic to use. But then as you add additional tracks that use the same recording this could affect what is now returned as the recording title, so the recording title is unstable in that it changes depending what tracks have been added UNLESS a recording title is actually entered for the recording, then this always returned, we now have the situation that the recording can either be entered or derived from track title, so ist being used for two different things. I have to say this seems a completely unworkable solution.


Oliver Charles added a comment - 28/Dec/11 02:08 PM

with option 1 when you first create that recording as part of the creation of the first track assuming you dont enter a different recording title to the track title the recording will have the same title as the first track whatever heuristic to use. But then as you add additional tracks that use the same recording this could affect what is now returned as the recording title, so the recording title is unstable in that it changes depending what tracks have been added UNLESS a recording title is actually entered for the recording, then this always returned, we now have the situation that the recording can either be entered or derived from track title, so ist being used for two different things

Correct. But I don't think in practice this is actually a huge problem. It's just akin to someone actually doing an "edit recording" edit at the same time – either way the recording title will change. It just means there's less of a paper trail, no peer review, etc. So I won't argue it being unworkable


nikki added a comment - 29/Dec/11 12:02 AM

I prefer the second option. I would add something to the recording tab to let people say they want to copy the changes to the recordings.

I don't really like the first option, it seems like it would be quite confusing for recording names to sometimes change and sometimes not change depending on whether it was previously edited. I thought about having it so that the recording name always matches a particular release (determined by an algorithm), but it still seems problematic because of disambiguation comments:

We use disambiguation comments to distinguish things with the same name. If we let recording names automatically change, you could easily end up with something like "Some Title (radio edit) (radio edit)". If adding a disambiguation comment counts as adding a recording name, then doing that doesn't solve this ticket because you would still have to edit both manually if a recording has a comment.


MeinDummy added a comment - 29/Dec/11 01:22 PM

I'm also in favor of the second option.

However, I interpret the original ticket such that we'd generally like to be able to change track and recording titles in one step.
So an option to change recording titles if the track title is changed solves 50% of the ticket.
The other 50% would be something like presenting the editor with a choice of tracks to be changed when he modifies the recording title. But that might better be moved to another ticket.


nikki added a comment - 29/Dec/11 02:06 PM

MeinDummy: Already has its own ticket - MBS-2970


Oliver Charles added a comment - 02/Jan/12 02:52 PM

As there are unanimous votes for the second option, I am going to re-open this ticket to implement that.


Oliver Charles added a comment - 02/Jan/12 03:49 PM

I've put my first attempt up on code review at http://codereview.musicbrainz.org/r/1692/. This is available for testing on http://test.musicbrainz.org/ – please tell me what I've got wrong


Oliver Charles added a comment - 03/Jan/12 05:28 PM

Good news everyone! This is now in beta testing at http://beta.musicbrainz.org, which means it can be tested against the live database.