libquicktime-devel

[Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

Hi —

It appears that qtinfo’s multichannel audio handing is simplistic and isn’t looking in the correct place for information.

A 4 channel audio file (produced with Quicktime Player)  produces this output from qtinfo:

[mini:x/QuadroPopParty] sms% qtinfo 4.mov
in quicktime_get_chan
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: [1]Front Left, [2]Front Right, [0]Unknown, [0]Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.
[mini:x/QuadroPopParty] sms% qtinfo 4.mov
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: Front Left, Front Right, Unknown, Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.
[mini:x/QuadroPopParty] sms% qtinfo 4.mov
Type: Quicktime
  1 audio tracks.
    4 channels, 24 bits, sample rate 48000, length 99918240 samples, compressor lpcm.
    Sample format: 32 bit signed.
    Channel setup: Front Left, Front Right, Unknown, Unknown
    Language: eng
    supported.
  0 video tracks.
  0 text tracks.

After a morning of puzzling over this and seeing only that multichannel.c is an incomplete subset of chan.c I remembered that qtdump might help.

qtdump says about the stsd atom:

    sample table
     sample description (stsd)
      version 0
      flags 0
      total_entries 1
       format lpcm
       reserved 00 00 00 00 00 00 
       data_reference 1
       version 2
       revision 0
       vendor xxxxx
       channels 4
       sample_size 24
       samplerate                     48000.000000
       formatSpecificFlags:           0000000e
       constBytesPerAudioPacket:      12
       constLPCMFramesPerAudioPacket: 1
       channel description
        version                     0
        flags                       0
        mChannelLayoutTag:          0x00000000 [Use channel decriptions]
        mChannelBitmap:             0x00000000
        mNumberChannelDescriptions: 4
         mChannelLabel[0]: 0x00000001 [Left]
         mChannelFlags[0]: 0x00000000
         mCoordinates[0]: [0.000000 0.000000 0.000000]
         mChannelLabel[1]: 0x00000002 [Right]
         mChannelFlags[1]: 0x00000000
         mCoordinates[1]: [0.000000 0.000000 0.000000]
         mChannelLabel[2]: 0x00000021 [Rear Surround Left]
         mChannelFlags[2]: 0x00000000
         mCoordinates[2]: [0.000000 0.000000 0.000000]
         mChannelLabel[3]: 0x00000022 [Rear Surround Right]
         mChannelFlags[3]: 0x00000000
         mCoordinates[3]: [0.000000 0.000000 0.000000]

Ah ha - so the quicktime file is correct and qtinfo is wrong.

Seems that qtinfo uses the multichannel.c module rather than the quicktime_chan_dump logic of chan.c.

is there a reason multichannel.c is around instead of using the logic in chan.c?

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Burkhard P. <bur...@ig...>]

Hi,

Am 04.03.2015 um 18:13 schrieb Steven Schultz:
> Hi —
>
> It appears that qtinfo’s multichannel audio handing is simplistic and isn’t looking in the correct place for information.
>
> A 4 channel audio file (produced with Quicktime Player)  produces this output from qtinfo:
>
[...]

> Ah ha - so the quicktime file is correct and qtinfo is wrong.

You are the first who reports about a wrongly labeled file more 8 years after I programmed that,
so it can't be that bad :)

> Seems that qtinfo uses the multichannel.c module rather than the quicktime_chan_dump logic of chan.c.

The problem is that chan.c defines an insane number of channel labels. So I decided to
simplify things a bit and define the LQT_CHANNEL_* enum, which is defined according to
real-life files and codecs like AC3, DTS or AAC.

> is there a reason multichannel.c is around instead of using the logic in chan.c?
The channel locations (as shown by qtinfo) are *always* taken from the chan atom (shown by qtinfo),
if that exists.

The mapping from chan atom channels to LQT channels happens in chan.c:

static struct
   {
   lqt_channel_t lqt_channel;
   channel_label_t channel_label;
   }
lqt_channels[] =
   {
     { LQT_CHANNEL_UNKNOWN,            CHANNEL_LABEL_Unknown },
     { LQT_CHANNEL_FRONT_LEFT,         CHANNEL_LABEL_Left },
     { LQT_CHANNEL_FRONT_RIGHT,        CHANNEL_LABEL_Right },
     { LQT_CHANNEL_FRONT_CENTER,       CHANNEL_LABEL_Center },
     { LQT_CHANNEL_FRONT_CENTER_LEFT,  CHANNEL_LABEL_LeftCenter },
     { LQT_CHANNEL_FRONT_CENTER_RIGHT, CHANNEL_LABEL_RightCenter },
     { LQT_CHANNEL_BACK_CENTER,        CHANNEL_LABEL_CenterSurround },
     { LQT_CHANNEL_BACK_LEFT,          CHANNEL_LABEL_LeftSurround },
     { LQT_CHANNEL_BACK_RIGHT,         CHANNEL_LABEL_RightSurround },
     { LQT_CHANNEL_SIDE_LEFT,          CHANNEL_LABEL_LeftSurroundDirect },
     { LQT_CHANNEL_SIDE_RIGHT,         CHANNEL_LABEL_RightSurroundDirect },
     { LQT_CHANNEL_LFE,                CHANNEL_LABEL_LFEScreen },
   };

Channels 3 and 4 of your file have the fields CHANNEL_LABEL_RearSurroundLeft
CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So they
are labeled as "Unknown" by qtinfo.

Maybe the most pragmatic solution would be to map CHANNEL_LABEL_RearSurroundLeft and
CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and LQT_CHANNEL_BACK_RIGHT
respectively.

Another possibility would be to make the chan atom visible in the public API, but I
don't know it it worth the effort. The defitions are so messy and redundant that it's
better to keep them private.

Burkhard

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

On Thu, Mar 5, 2015 at 8:59 AM, Burkhard Plaum <
bur...@ig...> wrote:

> Hi,
>
> You are the first who reports about a wrongly labeled file more 8 years
> after I programmed that, so it can't be that bad :)
>

no, not bad at all.  took that long for multi-channel audio to catch my
interest in earnest.


> The problem is that chan.c defines an insane number of channel labels. So
> I decided to
> simplify things a bit


hmmm - the duplication made the situation seem more complex and harder to
see what was going on.   somewhat like the adage  "any problem in computer
science can be solved by another layer of indirection" :)


> and define the LQT_CHANNEL_* enum, which is defined according to
>  real-life files and codecs like AC3, DTS or AAC.
>

LPCM is a codec and predates all of those  <g>


> static struct
>    {
>    lqt_channel_t lqt_channel;
>    channel_label_t channel_label;
>    }
> lqt_channels[] =
>    {
>      { LQT_CHANNEL_UNKNOWN,            CHANNEL_LABEL_Unknown },
>      { LQT_CHANNEL_FRONT_LEFT,         CHANNEL_LABEL_Left },
>      { LQT_CHANNEL_FRONT_RIGHT,        CHANNEL_LABEL_Right },
>      { LQT_CHANNEL_FRONT_CENTER,       CHANNEL_LABEL_Center },
>      { LQT_CHANNEL_FRONT_CENTER_LEFT,  CHANNEL_LABEL_LeftCenter },
>      { LQT_CHANNEL_FRONT_CENTER_RIGHT, CHANNEL_LABEL_RightCenter },
>      { LQT_CHANNEL_BACK_CENTER,        CHANNEL_LABEL_CenterSurround },
>      { LQT_CHANNEL_BACK_LEFT,          CHANNEL_LABEL_LeftSurround },
>      { LQT_CHANNEL_BACK_RIGHT,         CHANNEL_LABEL_RightSurround },
>      { LQT_CHANNEL_SIDE_LEFT,          CHANNEL_LABEL_LeftSurroundDirect },
>      { LQT_CHANNEL_SIDE_RIGHT,         CHANNEL_LABEL_RightSurroundDirect },
>      { LQT_CHANNEL_LFE,                CHANNEL_LABEL_LFEScreen },
>    };
>
>
OK - that's the piece of the puzzle that I overlooked or didn't realize the
significance of.  Thanks!


> Channels 3 and 4 of your file have the fields
> CHANNEL_LABEL_RearSurroundLeft
> CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So
> they
> are labeled as "Unknown" by qtinfo.
>
> Maybe the most pragmatic solution would be to map
> CHANNEL_LABEL_RearSurroundLeft and
> CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and
> LQT_CHANNEL_BACK_RIGHT
> respectively.
>

Hmmm, the idea of calling 'surround' and 'rear surround'  the same thing
bothers me.  They have different ID numbers and there are systems (not mine
-   Yet :) that have surround and rear surround channels.

Would it be OK if I added "LQT_CHANNEL_Rs" and "LQT_CHANNEL_Ls" (or similar
if you have a  better idea for the name) for the Right and Left and mapped
them to CHANNEL_LABEL_RearSurroundRight and CHANNEL_LABEL_RearSurroundLeft
respectively?

ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
to add.

Another possibility would be to make the chan atom visible in the public
> API, but I
> don't know it it worth the effort.


Would be nice - but only if someone else does the work <grin>


> The defitions are so messy and redundant that it's
> better to keep them private.
>

Is there nothing that could be done to clean 'em up and perhaps remove some
of the redundancy?  Feels like a waste to have all that work/effort just
sitting there not publicly available.

Thanks for the hint!

Cheers,
Steven

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Burkhard P. <bur...@ig...>]

Hi,

Am 05.03.2015 um 18:12 schrieb Steven Schultz:

[...]
>>
> OK - that's the piece of the puzzle that I overlooked or didn't realize the
> significance of.  Thanks!
>
>
>> Channels 3 and 4 of your file have the fields
>> CHANNEL_LABEL_RearSurroundLeft
>> CHANNEL_LABEL_RearSurroundRight for which no LQT_* equivalent exists. So
>> they
>> are labeled as "Unknown" by qtinfo.
>>
>> Maybe the most pragmatic solution would be to map
>> CHANNEL_LABEL_RearSurroundLeft and
>> CHANNEL_LABEL_RearSurroundRight to LQT_CHANNEL_BACK_LEFT and
>> LQT_CHANNEL_BACK_RIGHT
>> respectively.
>>
>
> Hmmm, the idea of calling 'surround' and 'rear surround'  the same thing
> bothers me.  They have different ID numbers and there are systems (not mine
> -   Yet :) that have surround and rear surround channels.

To my understanding (and in other audio systems), "Surround" channels always mean
rear channels. I remember that this stuff was extremely poorly documented, it wasn't
even a Quicktime documentation. It was a documentation of the Apple
"Core audio format" and by accident I found out that the multichannel definiton is the
same as the chan atom in Quicktime files. So it can well be that I guessed the
meanings of the channels somewhat wrong.

> Would it be OK if I added "LQT_CHANNEL_Rs" and "LQT_CHANNEL_Ls" (or similar
> if you have a  better idea for the name) for the Right and Left and mapped
> them to CHANNEL_LABEL_RearSurroundRight and CHANNEL_LABEL_RearSurroundLeft
> respectively?

Can be. But I still wonder if there is a system with "Surround" plus "Rear Surround"
speakers, where would they exactly be located? Are the channel positions better
documented by now?

> ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
> to add.

Go ahead :)

> Another possibility would be to make the chan atom visible in the public
>> API, but I
>> don't know it it worth the effort.
>
>
> Would be nice - but only if someone else does the work <grin>
>
>
>> The defitions are so messy and redundant that it's
>> better to keep them private.
>>
>
> Is there nothing that could be done to clean 'em up and perhaps remove some
> of the redundancy?

Yes, if you are an Apple Engineer with enough influence to make an incompatible
change to the Quicktime format....

chan.c (like most other files) is nothing but a Quicktime atom implemented
in a C file. Thus, the C-definitions are as messy/redundant/crappy as the original
Quicktime atom.

> Feels like a waste to have all that work/effort just
> sitting there not publicly available.

Well that's a common symptom in the whole Quicktime format. Internally there is
*lots* of stuff defined, but only a tiny subset is actually used.

Burkhard

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Steven S. <sch...@gm...>]

On Fri, Mar 6, 2015 at 3:40 AM, Burkhard Plaum <
bur...@ig...> wrote:

> Hi,
>
> To my understanding (and in other audio systems), "Surround" channels
> always mean
> rear channels.


It's true that is  how many people set their systems up.  And it was the
usual layout for the quadraphonic systems in the 1970s.- ahead of its time
- the format failed then but today is back with more channels than ever.

I remember that this stuff was extremely poorly documented, it wasn't
> even a Quicktime documentation. It was a documentation of the Apple
> "Core audio format" and by accident I found out that the multichannel
> definiton is the
> same as the chan atom in Quicktime files. So it can well be that I guessed
> the
> meanings of the channels somewhat wrong.


Seems that accidents are how much of Apple's formats are discovered.  It
was by accident that I stumbled into this "problem" - I was assigning, in
the Quicktime 7 application, the channel layout of a Quicktime file's audio
track and selected the wrong choice.  Both 'surround left/right' and
'surround rear left/right' were offered.  I picked the 'rear' and then
qtinfo was saying unknown but the AV receiver played the file fine.  So off
to the mailing list and here we are :-)

>
> Can be. But I still wonder if there is a system with "Surround" plus "Rear
> Surround"
> speakers, where would they exactly be located? Are the channel positions
> better
> documented by now?


In a 5.1 system the surround speakers are almost parallel to the listening
position but slight behind.   It's in a 7.1 system that the rear surrounds
are directly in back of the listening position.

I'll include a picture from my AV Receiver's manual showing the speaker
positions for up to  an 11.1 system

But the extreme low limit of message size on the mailing list might delay
things until the message is manually approved.

> ALSO needed is a 'Mono' mapping (id #42 as I recall) which is easy enough
> > to add.
>
> Go ahead :)


will do - that's today's project


>
> > Is there nothing that could be done to clean 'em up and perhaps remove
> some
> > of the redundancy?
>
> Yes, if you are an Apple Engineer with enough influence to make an
> incompatible
> change to the Quicktime format....
>
>
I'll see what I can do :)

Cheers,
Steven

Re: [Libquicktime-devel] qtinfo vs qtdump multichannel audio info

[Burkhard P. <bur...@ig...>]

Hi,

Am 06.03.2015 um 15:45 schrieb Steven Schultz:
> In a 5.1 system the surround speakers are almost parallel to the listening
> position but slight behind.   It's in a 7.1 system that the rear surrounds
> are directly in back of the listening position.
>
> I'll include a picture from my AV Receiver's manual showing the speaker
> positions for up to  an 11.1 system

Very good, thanks a lot. You can "fix" the channel definitions, but it would be
great to have some documentation for the channel labels in the header file
e.g. "Left Rear channel in a 5.1 system/Side channel in a 7.1 System" or whatever
you think is correct.

Also IIRC ffmpeg also defines channel locations now. Would be great if lqt
wouldn't be completely incompatible with other APIs.

> But the extreme low limit of message size on the mailing list might delay
> things until the message is manually approved.

That's the reason people use image hosters and/or pastebin for larger data :)
In some parts of the world (I've been there), people have slow internet and/or
small inbox quotas.

Burkhard