User talk:Reosarevok/Recording Issues

From MusicBrainz Wiki
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
    1. I like the bit about track length inheritance on masters and mixes. However I haven't seen any users who want to be able to distinguish between tracks on the bit level. I thought that Warp did a while ago but it turned out that he didn't want that much information. I really do think that bit level information is beyond the scope of MB - if Amazon offers VBR V0 MP3 and iTunes offers M4A, that's their problem. We shouldn't have to duplicate our releases because of this. --LordSputnik (talk) 15:10, 7 January 2013 (UTC)
    2. I specifically suggested ignoring lossy encodings for this reason; I imagine there’s a far better chance that retailers would carry an identical lossless waveform—otherwise, we could throw that idea out entirely for digital releases. Indeed, such features may be considered out‐of‐scope, though I’d like them to be expressed at this time. Rochusw mentioned he would like dynamic range information for tracks/masters. jacobbrett (talk) 20:47, 7 January 2013 (UTC)
  17. ijabz
    1. I've read the discussions above, but failing to properly understand them especially this concept of recording being a mix.
    2. I see the current system as follows, recordings represent a particular studio/live recording of a song, every time the same studio/live recording appears on a release, the track should link to this recording. Different encodings of a recording (i.e wav/mp3) are just encoding of the same recording, ideally there would be a one-one mapping between a recording and an acoustid but its impossible to create such an algorithm, but the current one does a pretty good job. The current system puts the recording at the centre of things which seems correct as recordings are created and then put together as tracks on albums ecetera and of course one of the great things in NGS is that given a recording you can find all the releases it appears on (well you could if we merged more recordings). Also ianmcvordeo make the points that we do not have control over how acoustids work so if the luks concept is a one-to-one mapping to recordings we shold make changes to recordings that would conflict with this.
    3. So I'm happy with current situation and would not wish to change the nature of recordings which despite the absence of a definition I think to be understood pretty much as I said. The idea of recordings not having a their own lengths doesn't make sense to me, it would make more sense for tracks to automatically take length from recording if anything.
  18. Hawke (talk):
    I want:
    • To have to enter performance info as few times as feasible. (FRBR “expression”, “recording session”)
    • To be able to tie dynamic range measurements (i.e. DR14 loudness numbers) reliably to particular releases (master level? track level?)
    • To have information on all the times/places a particular performance (recording session) and master/remaster was issued/reissued. (i.e. answer the questions: “What releases do I need to acquire to have this performance (mix?)?” and “What releases have the best version (master?)” (e.g. no clipping, acceptable dynamic range, good analog transfers)
    • To not have to worry too much about which specific “thing” some random compilation has, regardless of whether that’s mix or master or what.
    • Some way to indicate that an initial analog recording is a different thing (master?) from its multiple digital transfers which often sound different from each other.
  19. monxton
    • I agree with everything ianmccorvidae said above.
    • I won't disagree with any solution provided:
      1. solution has a single entity (recording group or whatever you want to call it) which can hold all the data related to the creation of the performance - e.g. who played the sax solo - and which need be entered only once however many mixes exist, and
      2. the occasional editor does not have to get to grips with an additional abstract entity level.