-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rotter supports FLAC, WAV, MP3, Vorbis. I've been using it in
production for lossless (4-week) archives and lossy (6 month) archives
for over a year and a half now. It's stable and works flawlessly.

Cheers,
James Harrison

On 05 August 2012 15:27:38, Chris Cramer wrote:
> Right. I forgot: rotter suports higher bitrates but no high quality 
> encoding...
>
> On Sun, 5 Aug 2012 16:15:32 +0200
> Chris Cramer <[email protected]> wrote:
>
>> Hi Wayne,
>>
>> I shrink the Audacity window to a minimum, so it ain't no problem pressing 
>> record in due time and cut the beginning second w/o audio signal afterwords.
>> Rotter works automatically according to its internal time schedule (every 
>> hour a new file) as far as I understand.
>> In addition it produces .mp3 in 128 kBit only - witch is way to poor for 
>> professional FM broadcast quality.
>> It is a nice tool for documentation purposes though.
>>
>> Cheers, Chris.
>>
>> On Sun, 5 Aug 2012 14:50:47 +0100
>> "Wayne Merricks" <[email protected]> wrote:
>>
>>> Lots of good info here, regarding Audacity for recording.  Would something 
>>> like rotter be easier considering you could automate it?  Having to click 
>>> record in Audacity seems a bit clunky to me or is there another mysterious 
>>> way of using Audacity that I don't know about?
>>>
>>>
>>> -----Original Message-----
>>> From: [email protected] on behalf of Chris 
>>> Cramer
>>> Sent: Sun 05/08/2012 13:39
>>> To: [email protected]
>>> Subject: Re: [RDD] RMS levels (some definitions)
>>>
>>> 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.
>> _______________________________________________
>> Rivendell-dev mailing list
>> [email protected]
>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
> _______________________________________________
> Rivendell-dev mailing list
> [email protected]
> 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/

iEYEARECAAYFAlAejx8ACgkQ22kkGnnJQAxRdQCdHtdYOR6shpHxvIq4VeqlOp2r
C1sAnAyO4PfWgWVMt9C2gnvbolXPHGMz
=NyMB
-----END PGP SIGNATURE-----

_______________________________________________
Rivendell-dev mailing list
[email protected]
http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev

Reply via email to