[vorbis] vorbis plugin (ACM codec)

[Florian Bruckner]

I've done an ACM codec for ogg vorbis beta 2 last summer, so maybe I can
give you some insight in what is possible and what is not. I do not know
whether Ingo's work will be based on mine, but that doesn't really matter.

What is ACM and what is it not
==============================
ACM codecs are a piece of software, that receives audio data in a memory
buffer and write audio data back to the memory buffer. ACM codecs have not
influence on what the "client" application does with the data.

Decoding audio
==============
Usually client applications read from WAV or AVI-files. Those files contain
a header which describes the decoders that have to be used to decode the
stream. The ACM is called and that looks into its registry whether the
necessary decoders are installed.

Encoding audio
==============
The client application has data in PCM and wants to encode it. The ACM is
queried which audio encoders are installed. The client application or the
user chosses which codec to use. Usually the client application writes the
.WAV or .AVI file with the encoded content, so any other .WAV or
.AVI-capable program can read it. The client application can also decide to
skip the .WAV-header and write the raw output of the encoder to a file. In
the case of my Ogg-encoder prototype, which simply generated an Ogg vorbis
stream the resulting file would be an Ogg file. I think Goldwave did this
for MP3, but I am not too sure about that.

You could also use an additional program which deletes all the .WAV-specific
structures from the file, resulting in a pure .ogg file as well.

Common problems
===============
.) Vorbis headers
Vorbis headers are embedded into the stream. This means that the codec has
to receive about 15K of data before actual audio data arrives. ACM-clients
behave strangely when they submit some encoded data to the codec and do not
get a bit of decoded audio back. This means that either the buffer sizes
have to be rather large (which in turn leads to problems, because there
seems to be a 128KByte size limit somwhere) or you return some 0-samples
when you do not have data.

.) packet size
As was already mentioned above, the buffer size can not be unlimited.
Because for every call audio data has to be returned the input buffer (and
therefore the corresponding output buffer) has to be large enough to receive
a ogg packet each call. If for some reason you cannot decode any audio with
the data you have, a 0-sample has to be returned.

.) variable bitrate
This is probably the most prominent problem, because it is mentioned
whenever it comes to ACM for either LAME or Ogg vorbis. The ACM codec
specifies the compression rate for an actual audio stream. The problem is
that this influences a couple of things:
1.) the input/output buffer ratio.
2.) seeking
3.) track-length display.

There may be some more problems, but those are the ones I remember.

Conclusio
=========
If the ACM interface was correctly implemented by all the applications
floating around, there shouldn't be a problem with Ogg vorbis codecs.
Unfortunetely even the specification provider (namely Microsoft) doesn't
care about its specification too much. Mediaplayer for example is one of the
worst examples I came across. On the other hand this is nothing we should be
surprised of ;-).

best regards,
Florian

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.