Richard G Elen wrote:
Not sure I see the point of bandwidth-limiting T. It was designed for
a world we no longer inhabit. We had issues with it at the time and I
don't think the considerations that made it useful for FM apply here.
--R
Nor do I see any point in this, or did I. Note that I was just laying
out some "general" framework, which is up for discussion. Yes, we have
enough bandwidth for 4 full-bandwidt channels (respective to
AAC/320kbps). You don't need any bandwidth-limitations for encoding T/Q
channels, agreed.
(The EBU has tested 5.1 AAC/320kbps, in 2007 or so. According to them,
the results were still in the "4" area, which means "very good" or
"near-transparent". Which just confirms once more that 3/4 channels
won't be a problem.
And there were former tests...
The MPEG-2 audio tests showed that AAC meets the requirements referred
to as "transparent" for the ITU <http://en.wikipedia.org/wiki/ITU> at
128 kbit/s for stereo, and 320 kbit/s for 5.1
<http://en.wikipedia.org/wiki/5.1> audio.
Certainly 90s?
Source:
http://en.wikipedia.org/wiki/Advanced_Audio_Coding
I personally think that the AAC stereo/5.1 rates (128/320 kbps
respectively) given above are not quite enough to be considered to be
reallt "transparent", but at least close ("near-transparent"). I have
recommended higher rates anyway, to be consistent with my own
believings. :-)
So, the "recommendation" was 80kbps/channel for symmetric coding
4-channel encoding, or maybe 96kbps/s for L/R and 64kbps for T/Q in the
asymmetric 4-channel case. With the help of existing and widely used
container formats like .M4p or Ogg, you could get around the 320kbps
limit of current stereo AAC decoders. The use of a container extension
implies that you would have some .aac stereo file inside, and another
container containing ;-) the UHJ extensions. Extract the .aac part from
the .m4p container, or set the filepath to the correct location. This
"prison break" solution doesn't work for streaming, though...
Just giving a bit more general background...)
Best,
Stefan
P.S.: AAC itself could and should go much higher than 320kbps, in the
case of multichannel applications. Unfortunately, even the EBU was < not
able > to test AAC above 320kbps some years ago. I personally believe
this is kind of embarassing, because it shows the "low status" of
surround sound. (A fictive log from the EBU test conversations: "Oh
damned, our AAC 5.1 encoder didn't accept any higher rate than 320kbps!
We can't compare to Dolby DD at 448kbps, 'cos look, there are different
bitrates and this should not be compared! This is because we tested AAC
encoding always for stereo input be4. Don't worry, we will fix this
problem in maybe two years.")
On 02/08/2013 17:09, Martin Leese wrote:
...
>- 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.
_______________________________________________
Sursound mailing list
[email protected]
https://mail.music.vt.edu/mailman/listinfo/sursound
_______________________________________________
Sursound mailing list
[email protected]
https://mail.music.vt.edu/mailman/listinfo/sursound
