#musicbrainz

kepstin-laptop: In general, it would be good to have less dropdowns and more autocompletes, IMGO.

though with the three-part interface you can do fancy things like promote values in one dropdown based on the values in the others

In my good opinion? IMHO.

ianmcorvidae: hmm, good idea - if you select english it would show top countries/scripts for english first in the other boxes.

Recorded directly to tape and pseudo-remastered for single-track .wav digital release.

>_>

https://tools.ietf.org/html/rfc5646 is the language tag spec i'm looking at, btw.

Freso: +1 for autocompletes

"zh-Hans" and "zh-Hant" for simplified vs. traditional chinese writing without specifying a region or dialect, btw.

that would be 'language: chinese, country: unset/any country, script: simplified chinese" or so.

then there's the really fun ones like "zh-cmn-Hans-CN (Chinese, Mandarin, Simplified script, as used in China)"

ah, right, they stick it in the order language-script-country.

initially we'd probably support <something from our language table>-<something from our script table>-<something from our country table>

which wouldn't include zh-cmn for example, but

yeah.

zh-cmn is kinda redundant, you can just do cmn

well, maybe it would, I guess we do have a billion frickin' languages in there

depends if we let people use non-enabled languages/scripts I guess :P

Does this look likea good deal to you guys? Want toupgrade my media server - http://www.ebay.co.uk/itm/Dell-PowerEdge-SC1425...

cmn is enabled

I wanted it for work languages :P

yue and nan too

well, sure, but I mean for things that aren't :P

https://www.iana.org/assignments/language-subta... is the official list of registered tags for that ietf syntax.

cmn is only registered as a subtag in that list, which means it must be used in combination with zh.

i think?

might be reading it wrong

you can use both zh-cmn and cmn

I mean, cmn isn't ambiguous

hmm. well, later on they have a mark saying that 'zh-cmn' is redundant, and that 'cmn' is preferred.

whether or not they allowi t

allow it *

http://rishida.net/utils/subtags/index.php?chec... http://rishida.net/utils/subtags/index.php?chec...

but yeah, I think just a UI update to the alias language setting, and storing data like country-script-language would work well for our purposes.

the ui update is the hard part, I suppose :)

storing the data is time-constrained in a rather specific fashion, given schema change, so you've got plenty of time to design it ;)

doesn't need a schema change tho; it's just a text field :)

I suppose the *meaning* of the field changes slightly.

oh, true, hm

I mean, it *should* be done as a link to a real locale table that links to the relevant language/country/script tables

but it's easily parsed so that part can probably be done later

yeah, these sort of tags are designed to be machine-readable

ianmcorvidae: That change is time-constrained in a rather specific fashion, given schema change, so you've got plenty of time to design it ;)

:P

*I* am not supposed to work on schema change stuff except on my own time until we're actually into the scheduled time for that :P

well, no vetoes yet, this is going better than expected

:P

is it an RFV? that's wrong, if so, it needs a second RFC if it's been substantially changed

which is my understanding

I suspect everyone is treating it as a second RFC

LordSputnik: "this includes remasters, if there is an audible, documented difference between recordings" <-- did you leave "audible" in there by mistake or did you mean it?

I'm asking because you removed other similar stuff saying they were subjective

ianmcorvidae: It's been through 3 RFCs or so by now.

ianmcorvidae: Each gradually changing it.

irrelevant, if it's substantially changed

ianmcorvidae: Anyway, that's up to nikki and reo to say, if it's "substantially changed" enough.

I'll look at it later, and make it clear that it's vetoed if I think it's changed enough, which by what I've read it almost certainly is

for now I'm off to see ruaok give a talk :)

I agree that it seemed to go to RFV too quickly. Even if the changes were not substantial, that thread is so ridiculously long that some of us need a while to read and digest it.

ianmcorvidae: I don't see what you're saying in the proposal process? The closest thing I see is "Any changes to the text of the RFC prior to sending an RFV clear that +1 and reset this requirement." which LordSputnik has fulfilled.

CallerNo6: Well, discussion seems to have halted on the proposal and branched off into other areas.

CallerNo6: Namely the Track/Recording revamp proposal that LordSputnik hasn't even finished yet.

*finished drafting

Right, but one would have to read the whole thing to know that :-)

There were two +1s, and discussion had finished, or at least, no-one was posting anything constructive about the proposal

Yeah.

Speaking of, I guess I have an RFV that passed yesterday.

kovacsur: the audible was left in there, since the "documented" was added to qualify it. it is still subjective, but the aim was to prevent recordings being created for remasters that were just marketing ploys with no substantial changes to the audio

kovacsur: plus, in some cases it would be possible to know if there were audible differences anyway without listening to it (news articles/blog posts/etc)

LordSputnik, I don't agree with that and I'll veto it if it's left in there. I really don't want people going "I can't hear any difference" "But I can!" etc.

well what would you suggest to replace it?

ianmcorvidae: it hasn't been changed at all between the RFC and the RFV

I think "documented" is enough, or you could change it to "audible OR documented"

hold on, let me check the original issue with it in the list

I was about to request that LordSputnik extend the RFV a couple days, but now it sounds like it's dropping back into RFC anyway.

kovacsur: So? If people can hear a difference, it should be two recordings.

tbh guys, you should've brought this up in the RFC

Freso, exactly, but they should also be separate if people can't hear a difference but they have different mastering credits

or if you null test them and see they are different

kovacsur: except that mastering credits generally go on the release.

kepstin-work: +1

I don't see a need to change this

LordSputnik, I would have, but then I saw it was already in RFV.

CallerNo6: I didn't see any new input to the actual proposal since at least the 12th.

and I also thought it was just a mistake

kovacsur: it'd been like that for a week

You won;t get subjective issues with that

because of the necessity of there being a documented difference

if someone hears a difference, and sees documentation saying there's a difference, then there's a difference

CallerNo6: I don't feel like looking back further than that, but that's at least a few days with no new discussion directly towards the RFC.

if someone hears a difference, but there's no mention of it anywhere, then that shouldn't be split

LordSputnik, my problem is people claiming they *can't* hear a difference and merging

even when it's documented

kovacsur: Vote no, then.

kovacsur: "audible || documented" still opens up for such merges.

but I also want this to go through :p

kovacsur: I was thinking on the specific merge. :)

ah, okay

Freso: that thread is huge. The longer it gets, the more time people need to consider it. IMO. I'm not saying LordSputnik broke the rules, just that I'd request (as a courtesy) an extension.

kovacsur: TBH, don't veto this and make a proposal for that specific change in the new guideline.

IMO “documented” is sufficient.

that is, if someone hears a difference, they should document it in the disambig and the annotation — problem solves.

*solved

CallerNo6: I'm not saying that you're saying LordSputnik broke the guidelines. :)

CallerNo6: Also, I don't necessarily disagree with extending the expiration.

pc crashed

CallerNo6: But I do disagree with no notion of letting it rot a week more as RFC when it's obvious that people would rather bicker about the not-even-close-to-being-implemented Recording Groups/Tracks-with-MBIDs/whatever system.

*with the notion

Ha! You only say that because your side is winning :-P

While we lowly "historians" just want to know who the guy playing cowbell was.

CallerNo6: which si why we need a performance thingy

anyway

kovacsur: if you make a proposal to remove the audible, i would agree to it

it's not that I'm against what you're saying, it's that I don't really want this to go back to RFC, as I don't think there'll be much to talk about, and the RFC thread will continue being a discussion about the problems with the current guidelines, and comments on recording groups

I'm happy to extend the RFV a few days

Would Sunday night be acceptable?

fine, I won't veto it then, it would have left me with a guilty conscience anyway

kovacsur: :)

Sunday night would be awesome!

CallerNo6: good, will extend it now

Thanks. And good job on navigating the system.

kovacsur: you might want to look at moving the "documented" bit so that it applies to the whole case too (the "different" masters bit too)

CallerNo6: ... I'm a "historian" as well.

tbh, I think the "historian" camp far outnumbers the "audiophile" camp

CallerNo6: (Actually, I'm probably more of a historian than the "historian" archetype that was listed, as I care for the same metadata - but much more granular than that.)

and it's not as clear cut as that

Fair enough.

Hm.

My main objection...

To https://musicbrainz.org/edit/19508852 is that one has a DualDisc medium, while the other is not set.

(Scared you there, eh LordSputnik? ;D)

However, using my duckduckgo-fu is showing me that the unset medium release is an "enhanced cd".