User talk:Reosarevok/Recording Issues

From MusicBrainz Wiki
Revision as of 10:24, 7 January 2013 by Jacobbrett (talk | contribs)
Jump to navigationJump to search

Please add new proposals to the bottom of the page, so that all the numbers stay the same for existing proposals!

For a summary of these ideas, please see Summary.


  1. Sput wants recordings to be mixes, tracks to be entities, and master entities to group tracks.
  2. Freso's thoughts
  3. warp just wants track ids
  4. mudcrow put some stuff here, though ian's linking it to this page
  5. User:Murdos is perfectly happy with the current system
  6. reosarevok would love more levels if and only if they're optional and shown to users only if they ask for them.
  7. Jesus said An MB recording is this song’s a recording session’s take, and we have some new sub sets of masters, cuts and mixes, as well as a DON’TKNOWWHICH catch-all special set in the same MB recording.
  8. nikki would like recordings to be mixes, but has some more detailed thoughts here
    1. reosarevok likes the sound of this (and while we're at that, he'll mention he wants something similar for works and arrangements)
    2. symphonick also wants recordings = mixes, and agrees that masters s/b @ release level
  9. User:Kepstin/Recording_Thoughts has a similar master level to nikki's proposal, and the addition of a higher level entity to group alternate versions, possibly with AR movement to reduce redundant data.
  10. The BBC has some thoughts too. They'd like recording groups, but that could just be because we're too cautious about merging recordings. Would be nice if we could get them to clarify. --Nikki (talk) 03:42, 20 December 2012 (UTC)
  11. symphonick's wishlist & thoughts
  12. caller#6 wants an FRBR "expression".
  13. forums thread
  14. rochusw also supports track ids and "DON'TKNOWWHICH" levels.
    1. I especially like the bit about tracks normally only having one AcoustID, very good point. EDIT: Obviously this is a decision for luks to make. I was just expressing my opinion that it's a good idea. --LordSputnik (talk) 12:43, 26 December 2012 (UTC)
    2. Anyone prescribing changes to AcoustID: Please read my comment on the forums thread. We do not control AcoustID -- luks will decide what AcoustID does with respect to this change, and I'm confident he'll decide better than any of us. Proposals should treat AcoustID as it is: a third-party entity. Ianmcorvidae (talk) 20:58, 26 December 2012 (UTC)\
    3. I don't see why editors can't make suggestions about how they'd like AcoustID to be more integrated with MB? If luks reads them and thinks they're good enough, there's no reason why he wouldn't use the suggestions... And besides, we can implement the idea in this proposal as a style guideline - "if you see more than one fingerprint on a track, examine it, and if it's wrong, unlink it". --LordSputnik (talk) 10:22, 30 December 2012 (UTC)
    4. You are free to say what you want and hope for miracles. However, if a proposal specifies anything that must/should happen on AcoustID's end, depends on any particular behavior of AcoustID (say: "acoustids are attached to {any particular level}", or inheritance of acoustids, or suggestions of "improving" acoustid in optimistic and vague fashions), or attempts to redefine the relationship between AcoustID and MusicBrainz, it will fail. AcoustID is not part of MusicBrainz, and for both legal and preference reasons neither side is interested in them merging, even to the very minimal level of MusicBrainz having a copy of the AcoustID database. We've discussed these topics a number of times since AcoustID came into existence; if this discussion of recordings is happening I'd like it to stay focused on things that we can actually change, which doesn't include AcoustID. Ianmcorvidae (talk) 11:03, 30 December 2012 (UTC)
    5. We can, however, propose that AcoustIDs links shouldn't be displayed on mixes, until luks decides how to proceed. That's completely our end - we just change the page to remove the AcoustIDs section, with no modifications to the links themselves or AcoustIDs. --LordSputnik (talk) 01:30, 5 January 2013 (UTC)
  15. ianmcorvidae is a curmudgeon who thinks the whole discussion is about symptoms of larger problems that we should focus on solving instead of making things more complex
    1. Both nikki's proposal and mine say that we need Master before we have Mix. If we remove the Master part of recordings without creating a new entity to put Master relationships on, we're going to waste a lot of time moving any production relationships into annotations and then back onto Masters when they're eventually made. If we create a simple, optional Master level before 2. and 3., it'll save editors time, and won't detract from any future modifications that may be needed once 2 and 3 have been done. --LordSputnik (talk) 10:35, 30 December 2012 (UTC)
    2. You have misread nikki's proposal: "If I had my way, I would simply define recordings as mixes and put mastering at the release level." and note that defining recordings as mixes is before the creation of masters in the bulleted list of the proposal. You have a highly optimistic view of what won't detract from MB, with which I as a developer and editor do not agree. Ianmcorvidae (talk) 11:03, 30 December 2012 (UTC)
    3. No, nikki says we should have masters because she's taking into account the views of other people: "However, in an attempt to satisfy masterists, here's my proposal:". The list with bullets isn't an ordered list. In her implementation suggestions, she clearly puts the schema change to make master in stage 1, while redefining recordings in stage 2. What detracts from MB is for the wider community to decide - I certainly can't say for definite, I'm just giving reasons why I feel it would be helpful. --LordSputnik (talk) 01:30, 5 January 2012 (UTC)
    4. The interpretation of nikki's proposal doesn't change mine. The relevant points of my proposal are that a.) we have bigger problems to be dealing with, and I think we're talking about schemas because we don't feel comfortable talking about them, b.) issues of recording-fuzziness are solved by definition as 'mix', since we already don't have effective tools for tracking master-related information (thus needing to actually consider interaction!), and c.) track IDs are largely an independent concern (though one I think is actually more important than this one). My metric for detriment is developer time taken away from other things (like fixing bugs), which is already a huge problem with 2 of 3 developers working on major new projects. Ianmcorvidae (talk) 02:18, 5 January 2013 (UTC)
  16. jacobbrett’s thoughts