On 09/06/13 23:54, Fred Gleason wrote: > On Jun 3, 2013, at 06:10 20, Richard Lamont wrote: > >> Yes, the problem is purely in the Edit Markers window. Worse than the >> rounding, if the cut gain in the database is below -10 dB it will >> increase the gain to -10 dB. > > So it does. This is because certain sound architectures --e.g. HPI -- are > limited in the amount of gain offset they can apply. This is what sanity > checks are all about.
Fair enough - I didn't realise that Rivendell didn't adjust the gain internally. >> I'm trying to set cut gains so the carts play at -23 LUFS. This often >> requires play gains around the -12 dB mark or lower. Having these gains >> increased to -10 dB every time someone does something on the cart, not >> necessarily related to gain at all, in the Edit Markers window is a >> serious bug IMHO. > > My opinion is a bit different. Setting the gain directly in the DB and then > complaining when the sanity check mechanism catches it is a bit like > bypassing the safety interlocks on a 50 kW transmitter and then complaining > that the manufacturer made an unsafe unit. We can certainly debate the > tradeoffs involved in the current design for handling level processing, but a > bug -- let alone a "serious" one -- it most certainly is not. To the > contrary, it's a deliberate part of the design. > > FWIW, this feature was never intended to be used in the way you are trying to > use it, but rather as a means to achieve relatively minor 'touchups' in trim > level. Fred - many thanks for this detailed response. Now that I understand of the design rationale, I can reduce the level of the audio on cuts that are >10 dB too loud. Initially I was reluctant to do this as I'm a stickler for quality and I'd assumed that when a cut starts as 16-bit PCM and ends as 16-bit PCM, the less done to it in the middle the better! However, the only effect will to raise the PCM noise floor from around -90 dB to maybe -75 dB, which nobody's going to notice. The problem I've got is that I've recently inherited responsibility for a system created by others. It has thousands of cuts on it and users are complaining to me, quite understandably, that the levels are all over the place. The station's format is fairly eclectic and cuts have been ingested from a variety of sources, ranging from lightly compressed speech items to recent CDs mastered ridiculously hot. (Where possible we tend to use older CDs, e.g. from the 1980s, which were mastered properly.) We're aiming to have a high-quality online stream that has no more processing than necessary. It isn't a participant in any loudness war. (Obviously FM has to be processed, but that's best left until just before the TX.) This means that we need good loudness control of the cuts on Rivendell. At the moment Rivendell provides for 'normalization' to so many dBFS. AFAIK the docs don't specify whether this is peak or RMS normalization. I'm guessing from the wide disparity of loudness levels we're seeing that it must be peak. RMS would be better because it correlates better with subjective loudness. Better still would be loudness normalization to ITU-R BS.1770-3 / EBU R128, which is just a kind of weighted RMS with a gate threshold. Then there's the whole question of Loudness Range (LRA), as defined by EBU Tech 3342. Ideally the importing/ripping process in RDLibrary would, optionally, be able to compress audio with an excessive LRA, to fix the "Wish You Were Here" problem. My 2p. -- Richard Lamont <[email protected]> _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
