Hi Ingo,>It is just a WAVEFORMATEX with a GUID in it. For the ACM system it is justa 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 thedata 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 specifiedformats. 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
Hi Daniel,> 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. > ...Which says nothing. The above text applies to renderers and capture filters, not to intermediate filters like compressors. Especially all standard AVI and WAV filters support the WAVEFORMATEXTENSIBLE structure, whether the docs state something different or not.> 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.So when the driver has to decompress the second file it creates a marker and the metadata and feeds it to the FLAC encoder. Or do you use a lower level API than the stream en/decoder from libFLAC?> 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.May I ask how?> 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 theThis may be a dumb question, but where in the registry did you find this?> 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.So, then which message shows the compression options dialog for ACM drivers. All drivers support the DRV_CONFIGURE message, which shows the control panel dialog. but the DDK says: <quote> The DRV_CONFIGURE message is one of the standard driver messages. A client sends the message by calling the driver's DriverProc entry point, passing the specified parameter values. Typically, this message is sent by the Control Panel's Multimedia applet. Drivers display a dialog box to obtain configuration parameters from the system administrator. Your driver must confirm that the client has Administrator privilege. </quote> which is an excerpt from the DRV_CONFIGURE reference in the DDK. Additionally the DRV_CONFIGURE message is usually sent to a driver, that was opened with no parameters (0 as argument to DRV_OPEN). So the options would have to be common for one driver instance. Unfortunately one driver instance can be used to open multiple streams, which should have their own diffferent options each. Another dialog is the ACMDM_DRIVER_ABOUT dialog, which has its counterpart in the ICM_ABOUT message. But only the ICM drivers have the ICM_CONFIGURE message for changing compression options. I can't find a similar message for the ACM drivers. Can you enlighten me here. As you already mentioned, Virtual Dub does not display a dialog for selecting compression options. But I assume some others do and you know at least one of them. Can you please give me a download link for an application that shows such a dialog. It would be helpful for testing. Thanks, Ingo