Occasionally someone on our staff will have to do their show live from their home studio. They'll use a tieline unit to send their voice to a channel on the console. Sometime's the intro of a song will drown them out. Is there an easy way to introduce Auto Ducking so that this doesn't happen? We use iMediaTouch v4 as our automation system. Our console is an Audioarts R55e. Any suggestions would be much appreciated.
-
Get involved.
We want your input!
Apply for Membership and join the conversations about everything related to broadcasting.
After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
If you use a disposable or false email address, your registration will be rejected.
After your membership is approved, please take a minute to tell us a little bit about yourself.
https://www.radiodiscussions.com/forums/introduce-yourself.1088/
Thanks in advance and have fun!
RadioDiscussions Administrators
Ducking Question
- Thread starter CTaylor
- Start date
Yeah but you don't want to run music through a wideband compressor intended just for ducking. Drum and base notes will cause pumping.
Most modern automation voicetracking applications allow for ducking the music when a voice track is inserted into the timeline. The talent can manipulate where the duck occurs around their track.
The problem is they're doing it live, just remotely (so voicetracking is not an option) and there's no one in the studio to adjust levels. And you're right, we don't want "pumping". (We're a mom & pop station without an on staff engineer (we have one on contract) so the owner wanted me to search for solutions before involving him.)
The typical solution for remote live talent? Board op.
Otherwise, about the only thing that comes to mind; is the ability to remote control the music channel level. I don't believe the Audioarts can be controlled with a GUI., so a less elegant solution might be your only option. For example; If your music appears on the console as a single fader channel, you might be able to connect a 3dB audio pad which could be switched in and out remotely. The pad would reduce the music level by 3db when the talent presses a phone touch tone * for example, then # to return the level to normal. Either that, or the pad could be inserted when the mic is turned on remotely. Problem with that idea, is if the talent turns the mic on long in advance of talking, the music will remained ducked.
Otherwise, about the only thing that comes to mind; is the ability to remote control the music channel level. I don't believe the Audioarts can be controlled with a GUI., so a less elegant solution might be your only option. For example; If your music appears on the console as a single fader channel, you might be able to connect a 3dB audio pad which could be switched in and out remotely. The pad would reduce the music level by 3db when the talent presses a phone touch tone * for example, then # to return the level to normal. Either that, or the pad could be inserted when the mic is turned on remotely. Problem with that idea, is if the talent turns the mic on long in advance of talking, the music will remained ducked.
H
Harvey_Dogg
Guest
No board op. In this case, all music in the automation needs to be normalized. I use 86%.
Some CD's use 86%.. Some use 133%. They use 133% to make the music sound like crap for anyone ripping a copy of the music. Get around this by recording the song as the CD plays. Then normalize it.
Some CD's use 86%.. Some use 133%. They use 133% to make the music sound like crap for anyone ripping a copy of the music. Get around this by recording the song as the CD plays. Then normalize it.
Last edited by a moderator:
Expanding on what Harvey Dogg posted-
This is a housekeeping problem... inconsistent levels between different program elements.
Solution is coming up with a plan that is acceptable to you and going through the effort to implement it.
Go on the Internet and read up about digital full scale, peak level, VU/loudness level and bit-resolution (aka bit depth).
Think about it, consider your source material, and decide what you'd like to do.
Everyone has their own cost/effort vs benefit analysis.
Here's a thought- do you use the same mic processor on all your mics? Main air studio and remote mics? The remote mics might be different models from the main air studio, but you could adjust for similar compression sound, EQ and dynamics between in-studio and remote mics. If this is not practical, can you get one more mic processor (identical to the one used in the air studio) and have a way to insert it into the remote site codec output at the studio when you need better consistency? If buying another mic processor is not possible, can you bridge the line input of your main air-studio mic processor across the audio output of the remote codec at the studio? Then switch between mic and line on the mic processor when needed and bring the remote up on the mic pot on the air studio console.
The above does not really solve the problem, but it gets you on your way.
This is a housekeeping problem... inconsistent levels between different program elements.
Solution is coming up with a plan that is acceptable to you and going through the effort to implement it.
Go on the Internet and read up about digital full scale, peak level, VU/loudness level and bit-resolution (aka bit depth).
Think about it, consider your source material, and decide what you'd like to do.
Everyone has their own cost/effort vs benefit analysis.
Here's a thought- do you use the same mic processor on all your mics? Main air studio and remote mics? The remote mics might be different models from the main air studio, but you could adjust for similar compression sound, EQ and dynamics between in-studio and remote mics. If this is not practical, can you get one more mic processor (identical to the one used in the air studio) and have a way to insert it into the remote site codec output at the studio when you need better consistency? If buying another mic processor is not possible, can you bridge the line input of your main air-studio mic processor across the audio output of the remote codec at the studio? Then switch between mic and line on the mic processor when needed and bring the remote up on the mic pot on the air studio console.
The above does not really solve the problem, but it gets you on your way.
Last edited:
Not everyone knows about normalization. Very useful post, Mr. Dogg!
Although this thread is somewhat aged, I thought that sharing this information would justify its resurrection:
That type of copy protection often only works against specific computer CD-ROM drives. Meaning you can circumvent it without having to record their playback in real time just by using a different drive (e.g. try different external USB CD drive models/brands). Other times, the issue can be circumvented by updating the CD-ROM drive's firmware.
Read this thread: Audio CD distorted when played on a PC - copy protection??
Way better to go this route than to sacrifice quality by re-digitizing formerly digital audio from conventional analog output players using sound cards of questionable quality!
P.S. I'm not even certain how this form of copy protection could be able to work. But I suspect it may have something to do with there possibly being some type of flag in the red book specification's metadata telling whatever drive is reading the disc to make volume adjustments to the 1s and 0 upon being read. It is possible that proper CD players do or don't obey this flag while cheap CD-ROM chipsets don't or do -- a difference that would create an attack vector against PC ripping that would not affect real players. I say this because the only alternative would be that such discs' songs were recorded with massive distortion built into the recordings, and that clearly would appear on every device playing them, not just on specific kinds. There is actually a similar mechanism of sorts built into the MP3 container format. Every frame of coded audio has a metadata flag that instructs the player how loud to decode the audio as. It can only be adjusted in increments as small as 1.5 dB. MP3gain used to make use of this flag to rapidly normalize MP3s without needing to transcode them (it simply read through an encoding's existing bytes, changing the specific bytes that represented this 1.5 dB flag). I often had to modify this flag myself when obtaining rare/out-of-print music from "unofficial sources" like Napster. What was happening was, people would rip their entire CD collections and put them online. But not before running MP3gain on every single MP3 so each had the same RMS volume. When indiscriminate people did this (teenagers, etc.), they would often try to make every song have a high RMS volume. The inevitable result: most of their MP3s contained 100% unclipped audio that clipped like crazy upon playback. Fortunately this could be fixed just by running them through MP3gain a second time at my end, so it could adjust all those volume flags downward. From then on, those MP3s played without any distortion, because the unclipped waveforms they contained, and had always contained, did not get rendered overamplified by the player. Anyway, I have a feeling some kind of metadata mechanism like this may be at play with red book format CDs and that the reason they play distorted in some drives but not others has to do with whether different classes of drives pay attention to those metadata flags. Which would explain why the thread above indicates that you can circumvent it just by trying different drives.
Last edited:
That happens everywhere here. Communities filled with intelligent, creative people often drift from discussing one fascinating subject to another. It can't be helped, only gently moderated. 
No thread hijacking was intended on my part. I just wanted to help Harvey_Dogg out with that information.
No thread hijacking was intended on my part. I just wanted to help Harvey_Dogg out with that information.
- Status