Long audio files fade glitch

[Nick Williams]

Hi All,

I am encountering a fade glitch when I use long audio files in my set.

If I fire a cue that plays a long audio file (30mins) and then fire a group to fade in with, for example,  a 15 second fade, the fade cues fire and but cues don't fade in. Instead they cut in abruptly at around 6 seconds. Previously I have shortened the long audio file and this has fixed the problem but I was wondering if I am doing something wrong or if there is a way to fix this fade-glitch?

Has anyone else encountered this problem?

Thanks for your help. Cheers,

Nick

[Nick Williams]

Hi All, 

I just deleted the long file and tried the fades again but the glitch remained. I'm fading in four 6min long files, is there simply a limit to how long a file I can use to get a smooth fadein?

cheers,

Nick

[Christopher Ashworth]

Good morning Nick,

Hm, the length of the files shouldn't be related to if they can be faded smoothly. (The same code used to draw the fade curve is used to compute the fade, so if it's smooth visually it will be the same aurally.) Could we see how you built the fades, e.g. by attaching a workspace file?

(mobile)

--
--

[Nick Williams]

Hi Chris,

Workspace file attached. I had to remove a lot of cues to make this small enough to upload. Regardless, the fades in this  workspace are still all glitching. My audio is 24bits 48000 sample rate.

It seems I'm experiencing the glitch on ALL fades, regardless of file duration. I'm using mutliple outputs (8) and, as in the case of the 'Washing Machine' cue, fading from centre to main l/r.

Macbook Pro 2010, 2.5GHz Intel Core 2 Due, 8GB Ram QLAB 3.1.15

Thanks for any help you can give me, I'm going in to tech week for a bug show tomorrow and this is making me very nervous!!

Cheers,

Nick

[Nick Williams]

Hi Again,

I just built a new workspace with one single file fading up and it still glitched. I updated to Qlab 3.1.15 this morning (I think), could it be a glitch with the update? If so, can I possibly revert back to 3.1.14 (I have been working in Qlab without any trouble all week)?

Nick

[Nick Williams]

I re-installed 3.1.14 and still encounter the same problem :(

Nick

[Chris Ashworth]

Hi Nick,

I don’t believe it’s a bug in QLab — I believe it’s something either in the programming or in your hardware setup.  (e.g. a gate that’s keeping it silent until it rises above a certain level)

Can you send the simple two-cue workspace to inspect? Always easiest to eliminate extra details.

Thanks!

Chris

[Nick Williams]

Hi Chris,

Thanks for your time. Attached is a two-cue workspace. Play the first cue and then use the second to fade in the file. It is cutting in rather than fading.

I just loaded a set I've been working on all week and it worked without any faults.

Thanks so much for your help.

Nick

[Chris Ashworth]

Hi Nick,

So, this workspace functions as I’d expect on my machine.  No cut-in, just a smooth fade up. (Although it does use the custom fade curve set to a linear progression, which doesn’t always sound as smooth as a different curve.)

Are you playing this straight to your headphones, or through a more complex output chain?

-C

Hi Chris,

Thanks for your time. Attached is a two-cue workspace. Play the first cue and then use the second to fade in the file. It is cutting in rather than fading.

I just loaded a set I've been working on all week and it worked without any faults.

Thanks so much for your help.

Nick

On Sunday, September 20, 2015 at 4:03:16 PM UTC+1, Chris Ashworth wrote:

Hi Nick,

I don’t believe it’s a bug in QLab — I believe it’s something either in the programming or in your hardware setup.  (e.g. a gate that’s keeping it silent until it rises above a certain level)

Can you send the simple two-cue workspace to inspect? Always easiest to eliminate extra details.

Thanks!

Chris

[Nick Williams]

Hi Chris,

The one I sent you works and then doesn't work. The worst kind of problem! I just reloaded it and its cutting in again 2secs after firing the fade cue regardless of whether I set it to S-Curve or Custom.

I'm playing it through a stereo setup but have my headphones monitoring output 3 and 4 so I can essentially monitor the first four outputs (1&2 speakers, 3-4 headphones).

Can Qlab handle 24bit 48K files?

Cheers,

Nick

[Chris Ashworth]

Hi Nick,

Yes, QLab will handle any bit depth and sample rate; generally speaking you don’t need to think about those things when using QLab.  (Although it’s worth thinking about which codec you use, but that’s another topic.)

Hm, when you say you’re playing it through a stereo setup, do you mean through an external audio device?  Does the behavior change if you plug directly into the headphone jack of your computer and test there?

Best,

C

[Christopher Ashworth]

Nick, 

It was brought to my attention off list that there may be a bug (or at least unexpected behavior) in how fade cues interpret the minimum volume level for the workspace.

If you lower the minimum volume level to, say, -90 dB, and change the fade curve to an s curve, does it sound different?

(mobile)

[Chris Ashworth]

Hi again Nick (and everyone else),

To follow up on my previous note, Mic Pool showed me a way that a workspace with a relatively high minimum volume level (e.g. -40 db) could result in the behavior you heard.

Specifically, if the workspace is set to have a min db level of -40, and you start a fade up from silence, it will be starting at actual silence, and the final volume will only turn into something audible when the fade gets around to the -40 db point in the course of the fade progression.

Put another way, the fade can spend a non-trivial amount of time between -INF and -40 decibels, causing it to “jump” in at -40 when it finally reaches the volume level that has been set to be “above silence” for the workspace.

After thinking about it a bit, I think this is the correct behavior, but it is certainly possible to force a fade cue starting from -INF to begin the fade at whatever minimum volume has been set in the workspace, thus allowing the full “audible" dynamic range of the fade to apply across the full time of the cue.

I don’t personally like that because it means -INF for a fade cue is different from -INF for an audio cue.  (Audio cues certainly need to have their -INF correspond to actual silence, I’d say.)  There’d still be a jump from silence, but it would be at the beginning of the fade instead of somewhere in the middle. 

Thus, I don’t think it’d be good to make the change, and would consider the pop in from silence to the MIN db as a design error rather than a QLab bug.

But… maybe I’m wrong?

-C

[Dave Tosti-Lane]

Interesting - I had always assumed that the purpose of setting a
minimum level was to REDEFINE "silence" to the point of inaudibility
in the space one is working. I understood this as a solution to the
problem you're describing with the fade. Maybe I'm missing another use
of the minimum level - but the reason I would reset it (usually to
around -60) was so that in a fade, none of my defined fade time was
expended BEFORE an audible change was applied.

Using that logic, I would expect an absolute fade to take my
re-defined minimum level as -INF, so that if I assigned a 10 second
fade up, it would start at (my redefined) just below audibility and
fade up to my desired cue level using all 10 seconds. Likewise, a fade
out should arrive at the inaudible point right at the end of the fade.
Then I would use the fade curve to control the pace of the change.

(-40 does sound a little high for that minimum level though -
suggesting that some gain stage adjustment might be in order.)

Dave Tosti-Lane

> --
> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53
>
> ---
> You received this message because you are subscribed to the Google Groups
> "QLab" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qlab+uns...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Christopher Ashworth]

Interesting. In this formulation would you then expect / want -inf on an audio cue to result in a potentially audible volume as well?

(mobile)

[Rich Walsh]

I'm not quite sure what the practical use of what is therefore essentially a noise gate would be? It is a regression to the joys of SFX 5.6 where we had to preheat everything to make fade-ins work and double the length of all the fade-outs so that the signal disappeared into the noise floor at the time you actually wanted it to…

It also contradicts how you explained this setting in 2010: https://groups.google.com/d/msg/qlab/kit3Lpfndbg/-Rq599D16XoJ.

Could you change it back to QLab 2 behaviour please, as the only way to avoid the "design error" of popping into audibility will be to set the preference to -INF to remove your gate, and then set a noise floor level on every audio and fade cue by hand.

Thanks.

Rich

[micpool]

I would say that the way it worked in QLab 2 was correct. i.e all fades started or finished at the minimum level and for the duration of the fade, providing the Minimum audio level had been set around the threshold of audibility (the  auditorium noise floor) a 10s fade would be heard as 10 seconds of changing level.

In the early days of computerised effects playback it would be a complete pain to have to manually set the threshold level for a fade in or fade out at -70 or whatever for the above to be the case. (even more so on playback programs that lacked a master level control so you had to set it for every output)

With QLab 2 for this to be automatic was a brilliant feature.

I am somewhat at a loss to explain why no one has noticed this feature was not carried over to QLab 3 despite most of us assuming it had. In my own workflow I would say that I tend to use Integrated fade envelopes for initial fade ups,  which work as I expect in QLab 3. e.g if the minimum audio level is -60 then the lowest level I can draw in is -60. 

Apart from that, the general increased noise floor from moving lights, projectors, hazers and associated fans has probably made the bottom end of fades less audible, until someone listens on headphones, or loudspeaker monitoring at high gain.

I have to say that to have a minimum audio level work as a gate is an entirely pointless feature. There would be no advantage in a noisy environment between having the Min Level set at -120 or -60dB. The point at which you were aware of the audio would be roughly the same. But subconsciously you would be aware of the difference between a fade below the threshold of audibility and a sound cutting in at that level many seconds after the fade had started. l. Listening again to complex sequences in old QLab 3 workspaces confirms this. The fades just sound late, or 10 sec fades only last 8 seconds. We would have been compensating with curves and timings to get things to sound right, but programming similar sequences as a test  in QLab 2 and QLab 3, the QLab 2 method is infinitely superior, faster and better sounding

Surely the whole point the MIN level was invented as a desirable feature in QLab 2 was to ensure that fades were audible for their entire length. I can't think of any other reason why it would have been incorporated otherwise. The fact that the QLab 2 method  survives in QLab 3 in  the  integrated fade envelope convinces me that the fact that the behaviour changed in fades was an oversight and this is one of the rare occasions  where I am incapable of seeing the other side of the argument. It is in my opinion  just plain wrong.

Mic

[Dave Tosti-Lane]

No - I think you misread me - I would set minimum level at just BELOW
audibility. Just at the point that I can no longer hear it. So, any
increase from minimum would become audible.

So -inf is still inaudible in the theatre space for an audio cue or
for the zero time point of a fade.

Dave Tosti-Lane

[John Leonard]

Rich Walsh wrote: Could you change it back to QLab 2 behaviour please,

&

Mic Pool wrote: It is in my opinion just plain wrong.


And I agree strongly with them (and can we also have a choice of how the integrated fade works when changing the start point of an audio file, please? I know, nag, nag, nag…)

Thanks,

John

[micpool]

No

Thats not what happened in QLab 2 either.

I think the sensible way to think of this is that a fade moves the SLIDER.

If the MIN  level is -60dB then the fader is at -60dB the moment it is  moved off it's end stop.

This is what happened with analogue faders. The end stop was off (signal shorted to ground) as soon as the fader moved onto the track the signal level was around -80dB (penny& Giles fader maximum attenuation) which means unless you were deliberately easing the fader off the end stop with no further travel, the transition from end stop to fader track meant the fade started at between -70 to -60dB

With computer sound playback, we started at  around 100dB about 10 years ago and by the time we got to QLab 3 were looking at -140dB when the slider left the endstop. This resulted in significant portions  of the fade being inaudible.

I thought this was  the entire reason the MIN audio level was invented, i.e to make the fades achieved using software sliders similar in feel to fades achieved using physical high quality faders.

Mic

[Andy Dolph]

+1 to the change.

My expectation in how a fade (or anything else in QLab) would work with that threshold would be what Mic described in the behavior of analogue faders.  That if the fader (automatic or manual) is at the very bottom of it's travel, then it's off. -inf.  The tiniest movement away from off, is to the set threshold (-60 or whatever).

--

[Christopher Ashworth]

LOL

Peace! Peace! I see the error of my ways! :-)

More when I'm not giving my kids a bath. :-)

(mobile)

[Chris Ashworth]

Okay, here’s what should be a fixed build:

http://figure53.com/temp/QLab-3.1.16-b1.zip 

I think I was focusing too much on the degenerate case of a very high minimum level, which would lead to a non-smooth bump somewhere and therefore seemed more or less equally wrong anywhere. I was missing the point that it’s critical to control the actual time over which the fade is audible.

Sorry for my confusion (and the bug, which I claimed probably wasn’t a bug — sorry Nick!)

-C

[micpool]

In my limited testing this seems to work.

There is still some complications to what happens to sliders in existing cues that are created at 1 MIN Vol setting and then the MIN vol is changed.

e.g plot at -100  then change Min volume to -60dB: slider now has a gap between bottom and first value off the end stop. 

I am not sure how this should work, but it's certainly worth playing with to see if the current behaviour is the optimum.

Mic

[Chris Ashworth]

To me it seems the levels of the cues which are set to -INF should then be reset to the new minimum level of the workspace at the moment it is changed.

I’ve filed a ticket in our issue tracker to this effect.