Hi Stephan,

Please note:

AAC/HE-AAC profile 1 uses Spectral Band Replication, which means that top
octave information is generated from lower frequency content using "hints."
 I'm unsure of the impact this would have on ambisonic decoding.   I guess
one could filter out the replicated contents and treat it as a band-limited
channel.

AAC/HE-AAC profile 2 uses parametric stereo, which is similar to Ogg Vorbis
Square Polar Mapping (described here http://xiph.org/vorbis/doc/stereo.html).
 This destroys phase information and I think would be unstable for
ambisonic content.  Can it be turned off in the encoder?

Aaron Heller (hel...@ai.sri.com)
Menlo Park, CA  US


On Fri, Aug 2, 2013 at 9:39 AM, Stefan Schreiber <st...@mail.telepac.pt>wrote:

> Martin Leese wrote:
>
>  Stefan Schreiber wrote:
>> ...
>>
>>
>>> To offer a backward-compatible extension of a < UHJ extended > AAC
>>> stereo file, you would have to include the T and Q audio channels as 3rd
>>> or 4th audio stream, somewhere. (Probably you could "label" such a file
>>> as stereo, the first 2 channels being L and R. Include some tags/flags
>>> in the header that there are one or two further < extension > audio
>>> channels, which would have to be decoded by a UHJ decoder. The decoder
>>> could be an app running on a smartphone, and the output could be a
>>> binaural version of the surround or actually LRTQ 3D audio recording.)
>>>
>>> If this "audio channels" approach doesn't work, use the "data"
>>> extensions of .mp4. (T and Q are not direct audio channels, so this
>>> might actually  be the formally correct approach... Because T and Q go
>>> into some decoder, as extension < data >.)
>>>
>>>
>>
>>
>>
>>
>>
>> Somebody would need to produce AAC test
>> files containing T and T+Q, and see what
>> existing stereo decoders actually do.  If existing
>> decoders cannot be made to ignore T and Q
>> (by fiddling with the file format) then the idea of
>> including T and Q is dead.
>>
>>
>>
> Certainly, but I see many ways to achieve this.
>
> Note that .aac is one thing, and .m4a and .m4p as container formats are
> something different. (Because Apple seems to mix these things a bit up, a
> decoder will play a "aac" stereo file in any of these variants, and it will
> be the same thing anyway. Speaking of extensions, it is not always the same
> thing. )
>
>
>  ...
>>
>>
>>> - The UHJ article already mentions that the T channel could be
>>> bandwidth-limited.
>>>
>>>
>>
>> Geoffrey Barton said some time ago that a
>> bandwidth-limited T-channel resulted in some
>> unwelcome compromises in the design of the
>> 3-channel UHJ decoder.  This may not be
>> such a problem with software decoders as you
>> could just include two separate decoders, one
>> for 2.5 channels and another for 3.  However,
>> this would mean a lot more work.
>>
>> I question whether the gain from band-limiting
>> T is worth the pain.
>>
>>
>
> No, I already wrote it is not worth it. (Better to use a lower AAC/HE-AAC
> bitrate for the full T/Q channel/channels, IMO.)
>
>
> Best,
>
> Stefan
>
> P.S.: Of course you would have to prove such a concept. If you have at
> least three ways to "fiddle" and two ways don't use hidden "audio" channels
> at all, things should really work.
>
> http://en.wikipedia.org/wiki/**MPEG-4_Part_14<http://en.wikipedia.org/wiki/MPEG-4_Part_14>
>
> "The existence of two different filename extensions, .MP4 and .M4A, for
> naming audio-only MP4 files has been a source of confusion among users and
> multimedia playback software. Some file managers, such as Windows Explorer,
> look up the media type and associated applications of a file based on its
> filename extension. But since MPEG-4 Part 14 is a container format, MPEG-4
> files may contain any number of audio, video, and even subtitle streams,
> making it impossible to determine the type of streams in an MPEG-4 file
> based on its filename extension alone. In response, Apple Inc. started
> using and popularizing the .m4a filename extension, which is used for MP4
> containers with audio data in the lossy Advanced Audio Coding (AAC) or its
> own lossless Apple Lossless (ALAC) formats. Software capable of audio/video
> playback should recognize files with either .m4a or .mp4 filename
> extensions, as would be expected, since there are no file format
> differences between the two."
>
>  Almost any kind of data can be embedded in MPEG-4 Part 14 files through
>> private streams. A separate hint track is used to include streaming
>> information in the file.
>>
>
>
> Which is the option which leads to >= 320kbps mode, as well. (I could
> figure this out. Not necessary as response to your posting.)
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mail.music.vt.edu/**mailman/private/sursound/**
> attachments/20130802/49823d7a/**attachment.html<https://mail.music.vt.edu/mailman/private/sursound/attachments/20130802/49823d7a/attachment.html>
> >
>
> ______________________________**_________________
> Sursound mailing list
> Sursound@music.vt.edu
> https://mail.music.vt.edu/**mailman/listinfo/sursound<https://mail.music.vt.edu/mailman/listinfo/sursound>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20130802/ee40d393/attachment.html>
_______________________________________________
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound

Reply via email to