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