[Flac-dev] ACM codec

[Daniel Souza]

Hi Ingo,

>It is just a WAVEFORMATEX with a GUID in it. For the ACM system it is just
a format with the id >WAVE_FORMAT_EXTENSIBLE and since ACM drivers are not
registered by wFormatTag it should be working. >For testing purposes I've
written a Vorbis ACM driver, that uses a WAVEFORMATEXTENSIBLE and I
experienced >a problem when opening files with Media Player. It spend quite
some time at 100 % CPU doing nothing (from the >users perspective). However
the problem might have come frome either the fact, that the driver was
compression >only or that it collided with a DirectShow filter, that I've
written for decompression. I haven't gone after it yet.

Here's an excerpt from the DirectX SDK documentation:
...
The particular format of a sound can be described by a WAVEFORMATEX or
WAVEFORMATEXTENSIBLE structure.
The wFormatTag member of this structure contains a unique identifier
assigned by Microsoft Corporation. The only tags valid with DirectSound are
the following:
WAVE_FORMAT_PCM. This tag indicates PCM, an uncompressed format.
WAVE_FORMAT_EXTENSIBLE. Multichannel audio format; valid only with WDM
drivers.
...

>another question. Does FLAC need the metadata at the beginning of a file.
Assume you open a FLAC file in >VirtualDub, for example. When you cut out
the first half of the WAV and the write out an AVI, the first half of the
data >is missing, which includes the fLaC magic number and the metadata. Is
this file still readable then? I think you >should put the marker and the
metadata into the WAVEFORMATEX (or WAVEFORMATEXTENSIBLE).
>
>I don't know if you do this, but you said, that all data is placed in the
data area.

The ACM driver responds windows messages with WAVEFORMATEX structures. The
ACM driver isn't responsible for keeping the data type information, the
client software is. AVI files are RIFF files, so the information returned by
the ACM driver in a WAVEFORMATEX is wrote in the RIFF structure. That's why
I said that there will be some data repeated. If VirtualDub splits FLAC
data, it's responsible for keeping the data type in the two result RIFF
structures. The data that the ACM driver will receive from the second part
when decoding will have not the "fLaC" marker and the metadata blocks. But
since the FLAC format is streamable (it has frame headers), it's not so bad.

>For format negotiation the driver must return a bunch of fully specified
formats. Then a suitable format is choosen >from the returned set by the
application and then set back as the output format for compression. At least
this is what >VirtualDub does. This means, that all available format
variations must be returned. I find this stupid, because the >more
compression options you have, the more different formats exist. This is at
least the case, when all required >information for decompression is put into
the WAVEFORMATEX, which is the case for my Vorbis filters.
>
>Do you see a problem here or does Virtual Dub not what it should?

The standard behaviour for an ACM codec is return a set of standard formats
for the data type. It's about samples per second, bits per sample and
channel number and not about compression options. The compression options
are set in a dialog provided by the ACM driver. The client software can ask
for a nonstandard format.

In VirtualDub you see a list of data types and a list of standard formats
for each data type. The strange thing is that there are sub-types. Looking
in the Windows Registry, I saw that each sub-type is registered as a
diferent type that use the same driver. The driver I wrote is based in the
IMA ADPCM driver code, that registers only one data type. The compression
options' dialog isn't available in VirtualDub for Audio. That's odd, because
the compression options' dialog is available for video when the driver
provide it, and the VCM is similar to the ACM. Anyway, the dialog is
available in the Control Panel.

Regards,
Daniel