On Mon, Aug 25, 2014 at 04:11:21PM -0700, Ralph Giles wrote: > On 2014-08-15 9:01 PM, Ron wrote: > > > So the patch applied for this part is now: > > > >> - If an encoder wishes to use R128 normalization, and the output gain is > >> not > >> - otherwise constrained or specified, the encoder SHOULD write the R128 > >> gain > >> - into the 'output gain' field and store a tag containing > >> "R128_TRACK_GAIN=0". > >> - That is, it should assume that by default tools will respect the 'output > >> gain' > >> - field, and not the comment tag. > > I agree this part is confusing. I think it's too terse to offer good > guidance. > > >> If a tool modifies the ID header's 'output gain' field, it MUST also > >> update or > >> remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present. > > This seems helpful in avoiding broken files.
Yes, I agree that part stands as a sensible MUST. About the only thing I could niggle about there might be s/update/correct/, but I don't personally think it's unclear what that indicates you should do or why (though I'm probably too close to this to be a good judge of that for other readers). And if we say 'correct' we might need a few words on, or a simple example of, what 'correct' actually is. > >> + An encoder should assume that by default tools will respect the 'output > >> gain' > >> + field, and not the comment tag. > > I read this as a non-normative should. Would it be better: I couldn't really decide whether that ought to be normative or not, mostly because I couldn't draw a useful distinction between "you SHOULD assume this because the standard says so" and "you should assume this because it's about the only sensible thing you can". Either way what we're really saying is "unless you have a good reason to believe otherwise, this is what you should expect", which fits with both normative and 'ordinary' use. (partly that question was in the context of us having a few other non-normative keywords we need to clean up still, I don't feel strongly about it going either way here) > "By default, implementations of this specification MUST respect the > 'output gain' field, but MAY NOT respect the comments. I'd be inclined to drop the "By default" there, unless we're going to expand on what the exceptions to the 'default' might be. > Encoder authors are advised to take this into account. In which case the normative language probably makes that sentence redundant. > For example, to produce R128 > normalized files it's more reliable for post-processing application to > update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0' > than to put the normalized value directly in the comment." Should the example there be ALBUM_GAIN rather than track gain (consistent with what we recommended before these changes, and with what is probably preferred in the absence of finer grained recalibration)? Maybe s/it's more reliable/it would be more robust/ ? (the distinction I see there being between what real apps _actually_ do in practice now and in the future, and what the standard guarantees you as being baseline support ... I don't have data on which is really more reliable, but I can tell you what the standard guarantees is most likely). But yes, I think that addresses the missing context I saw, assuming it doesn't also revert whatever it was Ian found confusing to remove it in the first place :) Ron _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
