-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's at https://github.com/JamesHarrison/iris but it's quite a bit OTT for just loudness normalization. I'm working on a little, simple tool to implement an EBU R128 dropbox that passes through file metadata nicely.
The EBU R128 spec is not standardized just yet, no, but in time it is almost certain it will be. And it is mostly compatible with good practice as it stands with classic measurement, just better tuned for the digital age. Digital true peak (the 4x upconverted supersampled peak reading) is a great measurement as are the other measurements in R128 (LUFS 400ms gated is awesome for overall program level measurements). Cheers, James Harrison On 05/08/2012 21:43, Chris Cramer wrote: > Hi James, > > thank you very much for the info, is your tool available anywhere? > I would like to try it out - if you don't mind. > > The EBU recommendation is a recommendation witch may / is expected to lead to a standard. > I do have the EBUmeter installed on my system for testing. > It is available from the KXStudio PPA for Ubuntu (I am using Ubuntu 10.04 on the production machines). > > Never the less, if one copies analogue material to a digital environment one needs to know what is going on level wise. > Therefore - as far as I understood there will be a new thing called true peak level. > > As far as I know the classic peak level measurement according to the standards > DIN 45406 / EBU / IEC 268-10 is NOT obsolete yet. > > Cheers, > Chris. > > > On Sun, 05 Aug 2012 16:27:30 +0100 > James Harrison <ja...@talkunafraid.co.uk> wrote: > >> > The EBU Loudness Recommendation R128 is pretty canonical for measuring > and normalising audio levels these days, at least in new professional > broadcast. libebur128 and tools based on it are available (like ebumeter > http://kokkinizita.linuxaudio.org/linuxaudio/ebumeter-doc/quickguide.html ) > and it's a very comprehensive specification. > > One of the measurements that is defined in EBU Tech 3342 is the loudness > range parameter, which is able to measure and display dynamic range of a > program. Using this and the R128 metering spec in 3341 along with the > production/distribution guides (3343/3344) you can do practically > anything to a defined, standardized set of best practices. The tool I > wrote for loudness/metadata processing, IRIS, uses libebur128 to process > audio to this standard and applies compression/adjusts gain to > standardize levels across a large range of input material including > speech, music and in-between stuff entirely automatically; it's not that > hard to automate. > > AES/EBU 'old' style metering and numbers are all well and good in an > established chain but EBU R128 supersedes the old EBU standards, and the > AES standards are very old hat these days. R128's the way to go if > you're looking for a standard to follow. > > Cheers, > James Harrison > > On 05/08/2012 13:39, Chris Cramer wrote: > >>> Hi all, > >>> > >>> About levels, > >>> > >>> this is a part of the mastering process of a recording and there might > be a reason why this is still done manually in the CD production process. > >>> Never the less as fas as I know there is only one product in the > market that is able to calculate and display a volume level of an audio > signal. > >>> That would be the Peak Program Meters (PPM) from RTW. And that is only > a display, not an algorithm for sound processing. > >>> This does not exist yet (as far as I know) as the material that is > supposed to be processed might be of totally different dynamic nature. > >>> A voice track has an other dynamic range than a classical music track > or a techno club track or a rock ballade for example. > >>> Therefore it is nearly impossible to pre program a one-fits-all algorithm. > >>> In my studio I do have a Jünger Audio digital dynamic processor that I > use for vinyl copies or raw audio material that was recorded live that > has to be processed. > >>> In my cart library I process manually watching my external ppm and > USING MY EARS to find a matching level. > >>> As I mainly use RIVENDELL for pre production I process the final show > using the JACK plugin JAMIN witch performs very good (without any > pumping) to produce a -0.2 dBFS audio stream I record using Audacity at > the same time. When finished I export the recording as .wav and process > it with lame in high quality. This file is then uploaded to the dropbox > of the broadcast computer and then aired as scheduled. > >>> > >>> About working levels > >>> I hear different opinions about levels in this group. > >>> > >>> There are clear definitions about levels in a professional broadcast > environment. > >>> > >>> First: 0 dBFS means the maximum level w/o distortion in a digital > environment (FS = Full Scale) > >>> > >>> In the area of the European Broadcast Union (EBU) the following levels > have been agreed on: > >>> > >>> Nominal Level and Test Tones: > >>> +6 dBU = 1,550 V = 0 dBr (VU) = -9 dBFS > >>> > >>> In the area of the Audio Engineers Society (AES) the following levels > have been agreed on: > >>> > >>> Nominal Levels and Text Tones: > >>> +4 dBU = 1.228 V = 0 VU = -20 dBFS > >>> > >>> Why? > >>> > >>> EBU > >>> +6 dBU was selected to produce a high signal/noise radio in a > symmetric line environment > >>> -9 dBFS was selected because large digital headrooms are not a > necessity in a pre processed audio signal environment > >>> 0 dBr is the 0 dB mark on a PPM > >>> > >>> AES > >>> -20 dBFS was selected to provide enough digital headroom in a live > signal environment in order to protect the live recorded material from > clipping in a digital environment > >>> > >>> CD / DVD production > >>> In the beginning of the digital audio age a CD was produced AAD > (Analogue Recording, Analogue Mastering, Digital Product): > >>> The recording was made on a analogue multitrack recorder such as > STUDER and then mixed down in a studio on a 2 track tape (mainly with > DOLBY SR or TELCOM C noise reduction). > >>> This tape was then processed in a PREMASTERING STUDIO. There this tape > was EQed and dynamically processed and then recorded on a U-MATIC > digital Audio Recorder with pq encoding. > >>> The pq encoding was the track, subtrack and pause marks as well as the > index (Table Of Contents, TOC) of the CD. > >>> As there was NO digital audio processing at that time it was a lot of > work to copy the analogue tape as the individual peaks had to be found > out first in oder to provide the maximum available dynamic range for the > recording. > >>> In addition there is an option called emphasis - this is some sort of > noise reduction in a digital environment. If you copy a CD digitally > there might be a change in the treble. That is caused by emphasis. The > track would need deemphasis. > >>> Today digital audio processing is the daily business in the recording > industry and therefore the recordings appear much louder. The typical CD > shows a level of -0.2 dBFS. Theoretically 0 dBFS would be possible and > some unprofessional mastering guys provide premasters like that to the > manufacturing plants. But it makes sense to keep masters at -0.2 dBFS to > ensure there is no digital clipping. Some CD players actually cannot > handle 0 dbFS and produce clipping during playback. In addition a > prolonged 0 dBFS is considered a digital clip as it is unknown weather > this really is a clipping of a signal that normally would extend above > the 0 dBFS or not... > >>> > >>> How to measure levels > >>> A classical VU meter is not aligned to integration times - therefore > it is not suitable for a professional level measurement. > >>> To measure a line audio level an integration time of 10ms has > internationally been agreed on > >>> To measure a digital audio level the peak sample is what counts. So > there is no integration time, the measurement time frame equals the > sampling rate. > >>> For the fallback time a value of 1.7s (+/- 0.3s) / 20 dB is acceptable > >>> The display range according to DIN 45406 / EBU / IEC 268-10 should be > -50dB to +9dB if used in an EBU environment > >>> It makes sense to provide a peak hold function and to use at least 200 > segments for accurate readability. > >>> RTW and other companies use different brightness values or additional > bars to display both the analogue and the digital integration time > measurement results and (in case of RTW) the calculated loudness at the > same time. However it appears to be a problem for most audio > applications to provide an accurate level display in their applications. > >>> Maybe a programmer would like to implement the above values into the > RIVENDELL working environment. I would love it! In addition it would be > GREAT if the user would be able to adjust the system level of RIVENDELL > according to its working environment display wise. I am located in the > EBU area and I work with -9 dBFS for 0 dBr (VU). So sadly the built in > Rivendell level meters will always display an incorrect level. > >>> > >>> Cheers, > >>> Chris. > >>> > >>> > >>> On Tue, 17 Jul 2012 09:06:11 +1200 > >>> "Gavin Stephens" <small.net...@gmail.com> wrote: > >>> > >>>> It took a long time but once done, it's done for good. Meaning I've > just done the manual adjustment route. > >>>> > >>>> I went through my tracks one by one and looked at them on a VU meter > (not peak meter and no normalisation), jumped the more louder part of > the track then just applied the amplitude (usually -5 to -8dB depending > on CD) to the track until the meter was close enough to 0dB and the > tracks sounded roughly the same as the last one. > >>>> > >>>> But I do that back in Windows since my favourite audio editor is > win32 only. I then import the final product in to Rivendell without any > further tweaking. > >>>> > >>>> I use the free standalone VU meter made by the guy that made VU > Player for windows to run along side of my editor, so I don't need to be > near a mechanical VU when roughly setting the volume of a track. I use a > -16dBFS 1KHz sinewave to calibrate the VU meter to 0dB since lower end > pro cards can only produce about 20dBu (like ASI5111, takeaway 16dB = > +4dBu normal average operating level). > >>>> > >>>> This pings the Rivendell meter about +4dB on average. But high end > cards sport +24dBu so there's 20dB of headroom and therefore you can use > -20dBFS tone to align them instead for +4dBu average output. > >>>> > >>>> It sounds like a lot of work, but because I've done my whole library > like that now, it only takes an extra 3-4 seconds when importing a track > for me. > >>>> ----- Original Message ----- > >>>> From: Fernando Della Torre > >>>> To: User discussion about the Rivendell Radio Automation System > >>>> Sent: Tuesday, July 17, 2012 7:00 AM > >>>> Subject: [RDD] RMS levels > >>>> > >>>> > >>>> Hello folks! > >>>> > >>>> I know this question has been here before and some of you have a > particular point of view about normalization as a way to keep levels > (peaks) at the desired numbers for technical and security reasons, as > avoid clipping. > >>>> > >>>> But at the same time, once we use peak normalizing there will be a > great loudness difference between the songs, and it's not good when you > have no operador to bring the faders up and take them down. > >>>> > >>>> To work around this situation I have been using the normalize > function to keep the peaks at -13db and manually set the play level gain > according to the necessary for each song, sometimes reaching more than > 5db of gain. > >>>> > >>>> How do you people handle this? > >>>> > >>>> I'm thinking about writting some code to analyse the wav files from > Rivendell and put a value in the play level using mysql, so they would > have allmost the same loudness, and my processor (no AGC here) would > work better. > >>>> > >>>> Would it be useful somehow? > >>>> > >>>> Opinions are always welcome! > >>>> > >>>> Regards, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Atenciosamente, > >>>> > >>>> > >>>> > >>>> Fernando Della Torre > >>>> > >>>> Tecnologia da Informação > >>>> > >>>> (: +55 16 8137-1240 > >>>> > >>>> (: +55 16 9137-2886 > >>>> > >>>> *: f...@vdit.com.br > >>>> > >>>> V.D.I.T. Soluções em Virtualização > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> A utilização deste e-mail não implica em autorização ou outorga de > poderes para seu usuário praticar qualquer ato em nome das empresas > citadas, cuja representação considera-se válida se praticada > exclusivamente por representante legal ou procurador devidamente > constituído, na forma estabelecida em seu respectivo estatuto ou > contrato social > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rivendell-dev mailing list > >>>> Rivendell-dev@lists.rivendellaudio.org > >>>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >>> _______________________________________________ > >>> Rivendell-dev mailing list > >>> Rivendell-dev@lists.rivendellaudio.org > >>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >> >> _______________________________________________ >> Rivendell-dev mailing list >> Rivendell-dev@lists.rivendellaudio.org >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > _______________________________________________ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAe3OcACgkQ22kkGnnJQAx2+ACdGxa0X+8s9FPW9YiI6zounTDx 53AAn3PHJM+RcHd6tuwzca/L5xfUqbIY =kdgK -----END PGP SIGNATURE-----
_______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
