[vorbis-dev] Transient coding: AAC vs. Vorbis

[Sebastian Gesemann]

On Thu, 10 Jun 2004, Segher Boessenkool wrote:

> You *can* have different transforms in Vorbis I files; they just
> won't be "standard", and so can't be decoded by standard decoders.

...and is of no use for me and my hardware player ;)
What's the point ? I do know that Vorbis I has a placeholder
for identifying a transform. So what ? What's the use of
a modified and incompatible Vorbis I stream ?

BTW: I'm quite happy with the MDCT anyway.

> And in 32kbps/channel you only have _NINETY-THREE_ bits per such
> a block _total_.

true. but
in case of a 93 bit packet this one bit does not hurt since
the whole packet has to be stored in octets ;)

> It can cause bad (i.e., not natural sounding) artifacts because
> it does some sort of blocking.
>
> Also, quite importantly for Vorbis, audio packets won't be
> independently decodable anymore.  You'll only need to go
> back a few packets to be able to decode it, but...

first, this "sort of blocking" is more a generalisation which
enables us to use packets that store 128,256,384,...,1024
samples per channel - not just 128 and 1024.

consider a signal which is first quasi static and then followed
by a transient attack. Vorbis I uses several short packets
before the attack where the signal is locally static. This
situation is very common, I guess. So, the ability to store
more short windows in one packet that share a floor curve
and/or the codebook classification codes because of a locally
static behaviour of the signal is an obvious improvement to
me.

second, the packets are still independently decodable.

third, as a positive side effect, the amount of wasted bits in
the last octet decreases in relation to the packet's size.


I just wanted to share this idea because I think this is one
of those things that needs to get improved for Vorbis II and
to make sure, that this will be addressed somehow.


Ghis!
Sebastian

--
PGP-Key-ID (long): 572B1778A4CA0707