Important news about QLab 3 and MP3s

[Sam Kusnetz]

Hello folks

Today, while testing a workspace that a QLab user was having trouble with, I uncovered an issue with playback of MP3 files that can cause QLab to exhibit around .08 seconds of delay before starting a cue. In this particular case, an MP3 file was playing, then a start-all Group cue triggered a very fast fade out of that file, and started another MP3 at the same time. What should have sounded more or less seamless instead sounded like there was a short prewait on the second file.

After recording and examining various examples of this behavior and comparing the results with other previously known issues related to MP3s, we’ve concluded that the only totally confidence-inspiring solution is to not use MP3s whenever timing within about 100ms is critical. This is not to say that you must’t use MP3s at all, only that when you do, it is possible there will sometimes be latency between hitting GO and hearing the cue.

This may not be too surprising, and in retrospect it seems pretty easy to understand why a heavily compressed audio codec could have timing problems even on a fast computer with a fast disk, but for us it feels nice to have finally seen a clean, repeatable example of this problem with a very clear fix: render the track to AIFF, and the problem disappears.

Cheerio

Sam

—

Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Christopher Ashworth]

To expand a bit further:

On Mar 3, 2014, at 12:29 AM, Sam Kusnetz <s...@figure53.com> wrote:

This may not be too surprising, and in retrospect it seems pretty easy to understand why a heavily compressed audio codec could have timing problems even on a fast computer with a fast disk, 

The act of decoding an mp3 itself can introduce silence at the top of the file. (It's not that it takes longer because it's more work to decide.)

Sam found that the old QuickTime based decoding in v2 generates different results than the CoreAudio / AVFoundation decoding in v3, at least on some files. 

The same MP3 file played in v3 thus was "delayed" compared to v2, where that meant that the decoding process was getting a little more silence on the top of the file.

Good to know for constructing tight sequences. (And we'll be sure to include this info in the docs.)

C

[Christopher Ashworth]

(mobile)

On Mar 3, 2014, at 6:35 AM, Christopher Ashworth <ch...@figure53.com> wrote:

To expand a bit further:

On Mar 3, 2014, at 12:29 AM, Sam Kusnetz <s...@figure53.com> wrote:

This may not be too surprising, and in retrospect it seems pretty easy to understand why a heavily compressed audio codec could have timing problems even on a fast computer with a fast disk, 

The act of decoding an mp3 itself can introduce silence at the top of the file. (It's not that it takes longer because it's more work to decide.)

Bah, "decode". Stupid iPhone typing.

[Paul Gotch]

On Mon, Mar 03, 2014 at 06:35:51AM -0500, Christopher Ashworth wrote:
> The act of decoding an mp3 itself can introduce silence at the top of
> the file. (It's not that it takes longer because it's more work to
> decide.)

In fact there are non-standard headers which account for this and allow
playback software which knows about them to correct for it. Apple
implemented this in iTunes in version 7 and above. However I'm not sure
they documented their method. There is also a tag used by many other
players based on a LAME Mp3 Info tag.

I'm not sure it's worth QLab attempting to support such things as it's
not going to universally apply to all MP3s so you instead of a simple
'MP3 is not exact use use WAV or AIFF' you end up with 'It might be
depending on how it was encoded or processed and if the metadata is
accurate or not'.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Sam Kusnetz]

On March 3, 2014 at 6:58:15 AM, Paul Gotch (paulg...@chiark.greenend.org.uk) wrote:

I'm not sure it's worth QLab attempting to support such things as it's 
not going to universally apply to all MP3s so you instead of a simple 
'MP3 is not exact use use WAV or AIFF' you end up with 'It might be 
depending on how it was encoded or processed and if the metadata is 
accurate or not'. 

It’s that first one. MP3 is not exact, use WAV or AIFF instead.

[Dave H.]

Do AAC files have the same problem?

[Sam Kusnetz]

> On Mar 3, 2014, at 12:31 PM, "Dave H." <rkoarmy...@gmail.com> wrote:
>
> Do AAC files have the same problem?

As far as I've been able to determine, no they do not. However AAC files are indeed compressed (sometimes lossy, sometimes lossless) so they do add overhead much the way that MP3s do. Therefore advice is the same for AAC/m4a files, though I have no specific proof that there is any serious problem with them the way there is with MP3 files.

Cheerio
Sam

[Paul Gotch]

On Mon, Mar 03, 2014 at 09:31:57AM -0800, Dave H. wrote:
> Do AAC files have the same problem?

AAC has the offset calculations as part of the standard itself rather
than as a non standard add on therefore any standards conformant
decoder should Do The Right Thing(tm) as long as the metadata is there.

However not all AAC encoders insert the right metadata, again iTunes
has since version 7. I don't know about other encoders.

It's best to stick with an uncompressed format such as WAV or AIFF or a
lossless format such as ALAC.

Anything which has gone through a lossy conversion at any point where
frame accuracy has not been preserved will have the problem.

[Riley]

I just had an issue with running Apple Lossless files up converted from mp3 running in QCart on OS 10.8.  Converting to AIF salved the problem.  Is this an OS thing or problems with Qlab/Qcart talking to the OS ?  The mp3s were created in Garageband as it turned out.

[Paul Gotch]

On 4 Mar 2014, at 02:48, Riley <e.rile...@gmail.com> wrote:
>
> I just had an issue with running Apple Lossless files up converted from mp3

The act of going through the MP3 (or indeed AAC) format at all leaves you open to the issue. Converting to a lossless format will either leave you with a fixed amount of silence in the new file 'baking the problem in' or if the original MP3 had the correct metadata in it and it was used while transcoding will leave you with a fixed file. Unless the converter reports about this kind of detail there is no way to know.

> running in QCart on OS 10.8. Converting to AIF salved the problem.

Are you sure? How was the conversion done? Did you convert from the MP3 in both cases or did you convert the ALAC files to AIFF?

If the latter then it's likely you are seeing a different issue.

-p

[Riley]

I realized after this came back on the digest that I had failed to say that the issue wasn't a silent patch at the start but rather drop outs on playback that occurred during playback from Apple lossless that was fixed by re-encoding the mp3 as an AIF.  Somewhat different from the original issue but harkening back to early issues in Qlab One with playback of mp3s directly.