Preparing sound files for a theatre's technician

[kgallen]

Some tips on assembling sound and playing sound effects from my experience:

-> Ensure the sound/effect starts at the beginning of each track - ie. no blank/silence before the sound starts after pressing "Play".

 

If there is "dead air" before the sound comes in, it is almost impossible to get the cue to run at the correct time. The only person who looks stupid when the "boink" comes a second after the rubber hammer hits the clown's head is the sound tech. I've been there - trying to anticipate when to press "Play" to a live action when there is leader on the track is next to impossible - even if that leader is only a few hundredths of a second long.

 

Some (MD) machines, and possibly software, can "cue up" to the actual sound on the track, but this is not ideal if the track fades in or if the cue's come in a quick sequence.

 

The same at the end of the track - trim the silence, otherwise the playback will not stop and cue the next track until that is finished and thus a quick sound cue following is not ready to play.

 

-> So edit the tracks accurately -> make sure you "top and tail" them.

-> Use headphones and listen critically when editing. Don't try and do this work listening through loudspeakers, worst of all those built into a laptop. When played out over a larger sound system any abrupt chops will be obvious and sound awful.

-> Make sure all in and out edits are clean or faded in or out to -70dB or better before cutting the track.

-> If editing a track that needs an abrupt start or stop within material then make the edit at a zero-crossing point otherwise there will be a loud "click" when the track starts or stops.

-> Scale to -20dBFS to provide headroom in a digital system to allow layering of sounds with other sources.

-> Make sure the audio quality of each track is comparable. It's awful to hear one good quality track and then follow it with a low quality one (that has been downloaded from a poor source on 't internet).

-> Use compression to tame an "excitable" track, especially if you're using it as a "bed" (background sound/music).

 

I'm sure there are a million more "top tips"...

Edited April 26, 2021 by kgallen

[Watson]

kgallen, most of that was familiar to me, but I'm grateful for the reminder.

[gareth]

Another recommendation for QLab - it's about as close to being an industry standard as anything. Well-prepared source files, normalised and edited nicely, set up in a neat, logical and well-labelled cue list in QLab for triggers, level changes and sstops, with a properly annotated script for the operator, along with some clear explanation of what's required and a chance to run it through with the talent to make sure everyone is singing from the same hymn-sheet, and you'll be in a pretty good position. Getting the right results is very much a function of asking for the right thing in the right way - so as long as you're clear about what you want the local operator to achieve, and give them the best resources you can in order to achieve it, you'll be OK. Edited April 26, 2021 by gareth

[Watson]

Another recommendation for QLab - it's about as close to being an industry standard as anything.

Thanks, and for your other thoughts too. Much appreciated.

 

...with a properly annotated script for the operator, along with some clear explanation of what's required...

Looking around online I've seen several varying examples of a marked-up performance script: is there a near-universally accepted industry standard for that, too? The two major variants appear to be a two-column approach or a layout which incorporates the cues into the body of the script (in the manner of stage directions) but clearly differentiated with coloured highlighting or distinctive fonts or other means.

Edited April 26, 2021 by Watson

[TomHoward]

Generally they’re in the text, well highlighted. If it’s at the top of a page, put a note on the bottom of the previous page so it’s not a surprise. Don’t forget to mark fade ups, downs, and ends of tracks if they don’t play right through in the same way, and don’t number them until you’ve added all the fades & stops.

 

If the sound action is to be timed specifically it can be easier to use actions in the middle of sequences rather than exact lines - that way there’s no ambiguity about whether it’s before, during or after if it’s a snap. Eg “Cue 9 the music snaps out when the actor touches their hair” or slams the mug down or soemthing - this way the actor can cue it too if need be, or it can be at the right point in a non-verbal sequence. I find them harder to get wrong if the script deviates slightly.

 

I have a colleague who always capitalises the word the cue should be hit on in the Qlab files notes, eg “who’s that at the DOOR it’s too late for visitors” would give me a better clue where to play the crashing thunder.

 

In case you’re not clear the fades and stops are also programmed in qlab as a “go” cue, so the fade isn’t usually done manually on a fader - qlab will increase or decrease the volume when “go” is pressed.

 

Make sure the laptop doesn’t have any passwords etc or they are stuck on it, if it’s to be operated by the house technician.

[Watson]

TomHoward, that's enormously helpful, thanks.

[gareth]

Looking around online I've seen several varying examples of a marked-up performance script: is there a near-universally accepted industry standard for that, too?

 

No, there's no one standard approach to this. General rule of thumb is to look at it from the point of view of someone who's never seen the show before, and has been tasked with operating the sound for it. Will they be able to establish, from the notes and markings in the script, what has to happen when? Could a modestly-capable sound operator step up and make a reasonable job of operating the show sight-unseen if necessary? If 'yes', then the way you've marked the script up is fine!

 

As someone who's had to deal with a fair few small-scale visiting shows over the years, I've seen my share of scripts which are marked up in a way which makes little, if any, sense to anyone other than the person who generated it. Or even worse, no script at all, just being handed a CD of badly-edited tracks with some vague verbal instruction to "play track 3 when you hear this line" or something similar. It's clear that you're not going to be 'that person', so that's great. Whenever I've had the misfortune to encounter that sort of poor-quality script, I've always made an effort to see that it left my venue in a better state than when it arrived - proper cue points, etc. written in where required, and so on.

[Watson]

Gareth, many thanks for that; great advice. One of my many previous jobs was as a script reader for the BBC's radio drama department and I know exactly what you mean by

 

I've seen my share of scripts which are marked up in a way which makes little, if any, sense to anyone other than the person who generated it.

since trying to decipher an unsolicited play script sent in by a would-be writer with huge enthusiasm but absolutely no idea at all of how to put what's in his head down onto paper, surely falls into a similar category of impossibility.

 

 

[TomHoward]

One other thought, which might be just me, but if you were a receiving house how many would actually need the MacBook and how many would just need the QLab file and script electronically?

If you knew your venues ahead, you could back up with sending a MacBook but a lot of venues might have a Qlab rig already available, and the sound guy could read the script through and check the file / cues beforehand.

 

If the script and the file are electronic it might be worth hosting them on a Google drive or similar and sharing the link ahead of time.. not everyone will prepare it, and have it ready and practiced before you arrive, but some might.

[Watson]

TomHoward, that's a very good point. If I'm right in thinking that the QLab file holds not only the names and sequence of the cues but also the audio tracks themselves, it would be perfectly straightforward to let the venue have the whole package ahead of time.

 

I'd still want the performer (or myself) to roll up with the company Mac so we'd be doubly backed up in the case of any problems.

 

Thanks.

Edited April 27, 2021 by Watson

[J Pearce]

You'd want to do a bundle save in QLab, then zip it before uploading, this should protect the filename structure. The QLab file itself holds just the instructions, but bundling a show creates a folder with the QLab file and all the content, with relative file paths that will handle being moved around.

 

As you've concluded, I'd still suggest having a macbook available, as not all venues will have a QLab rig on site, though most would be able to source one given suitable tech advances. For a simple audio only show a used macbook air would be plenty powerful enough.

[Watson]

For a simple audio only show a used macbook air would be plenty powerful enough.

I am actually pursuing exactly that. Many thanks for the information about the QLab Bundle save.

 

 

 

 

[alistermorton]

I'm no qlab expert, but does the show file include the patch? This is one variable that might not match e.g. our Qlab machine outputs (well, and inputs) over USB to the Soundcraft mixer but others may be using just the 2-channel built in audio or maybe a 4 channel or 8 channel interface.

[Watson]

I'm no qlab expert, but does the show file include the patch? This is one variable that might not match...

I'm not sure exactly what you mean by the patch: are you saying that somewhere in the show file might be the information which tells the computer how and where to output the final signal, and that information could override the resident host program's own setting? I can see that this could be quite a serious problem.

 

To be honest, it sounds a little unlikely that such a fundamental setting could be affected by data software, but of course you never know. If anyone can confirm whether or not this does happen, perhaps they could chip in. Thanks.

Edited April 27, 2021 by Watson

[J Pearce]

There's a layer of patch abstraction. The cue includes the selection of audio device (1-8), and the routing and levels of the file output to that patch's outputs. The settings window then allows you to choose a device for each patch.

 

This makes it pretty quick and simple to move a whole show onto another device assuming the channel count of the show is the same as or less than the channel count of the interface. It seems the show being discussed here is a simple stereo show, so that wouldn't be an issue. QLab does have room in the settings for another layer of abstraction that lets you route the patch's outputs to the device's outputs, allowing rerouting and downmixing. (I've used this when a show built for 8 outputs went on tour as a stereo show on the macbook's built in headphone socket).