ACM audio protection, developer, something, previous

andy

I've hacked some ACM audio support into AVISource, but it doesn't work properly. At least I can hear something from a few AVIs.

If some developer want to have a look, please do so.
* I'm not sure about calculations of stream length and seeking positions
* When you seek you hear the end of the previous buffer and I can't find the bug
* Don't ever hope for VBR support!
* It probably needs some protection against wrong stream headers
* Don't know how to handle audio skew.

Most of the code is in the following methods of AVISource: LocateAudioCodec, DecompressAudio, NextAudioChunk, AudioSeek and a bit in AVISource (the constructor) and GetAudio.
You have to add msacm32.lib to the library modules for the linker.

By default ACM audio decoding is not activated, as most of the time it barks an error message (and probably crash sometimes too), I added a boolean parameter to AVISource (amp; variants) to activate it:
AVISource(quot;test.aviquot;,true)

There is no binary in the attachment, because as I said it doesn't work properly (yet).

VDub's AVI reader is perhaps its best feature -- no bugs I'm aware of, and does a great job compensating for corrupted files amp; bugs in other programs.  We already use a lot of VDub code in this department; perhaps all we're lacking is a sync-up with the latest from Avery?

AFAIK, none of vdub audio code is in avisynth. I've written that with an eye on vdub sources, but maybe you're right, I'll look into a more direct integration. It's just that vdub sources are a little above my skills and at time a bit difficult to follow.

I've redone it using a different approach. I sync'ed virtualdub files with the current release of vdub and imported audio-related files. Adding audio support after that only involved about 10 lines of code, and adding a seek method in AudioStreamSource (it was only coded to allow streaming and skipping samples, not for random access. I hope i got it right).
All in all, it sums up to a ~50K bigger release dll.

Anyway it seems better now, most notably with files with wrong headers.

This time I attach a binary. There is still an optional boolean parameter to AVISource amp; co. to activate audio, but this time it defaults to true as I think it works better.

Note that you can also open standalone mp3 files with it, if you 'wavify' them before.

I'll wait a bit and if there are no complaints i'll add the code to the CVS.

Great job! Haven't tested it thoroughly but it seems like there's a lot of pent-up demand that'll do it for us

I suppose you suggested the next immediate feature: being able to add RIFF headers to arbitrary files.  I can't find source for WavMp3, but if anyone knows where something similar can be found (BeSweet perhaps?) let me know amp; I'll hack in a RiffSource() function.

The nandub sources should contain such a routine for the VBR mp3 stuff.
Too bad i don't have the sources anymore, but hopefully at 's download section you should find them.

Regards,
Koepi

I'd recommend staying away from Nando's audio-interleaving code.  That's a recipe for breakage.

Erm, the stuff for adding riff-headers could still be useful, don't you think?

I know of the problems avi has with vbr mp3, guess why I do that OGM stuff

Regards,
Koepi

Hehe thanks for the link, Richard.
I should have read this before starting. In my initial attempt, I was using a nandub avi+mp3 (do someone remembers the SBC intro  ) for debugging and scratched my head when I saw that nBlockAlign was the number of samples in an MP3 frame (why??).
I ended up with code that read this file correctly (even seeking worked) but didn't work with anything else. Then I changed it to correctly handles other files, but it broke Nandub files. That's the code I posted in my initial post above.
Now, with Avery code doing most of the work, it (seems to) work for both regular and Nandub files. I guess he implemented the work-around he talks about in this article.

Dividee -

Very cool.

But I don't know what ACM stands for. What types of audio can it now read? MP3? AC3?

If it could read ac3 somehow then we could save the name of the audio file in the d2v file and have mpeg2dec make it available, say to an MPEG2AC3Source filter. Doable?

- Tom

ACM is the windows pendant to VFW/WDM/DShow/DirectX for audio - the Audio Compression Manager (ok, the samples are a little too general  ).

It does the same as DShow does with the FourCC, it selects the right decompression codec AFAIK.

Regards,
koepi

Virtualdub uses ACM to open audio streams in AVIs. It can read whatever audio codec you can see in the 'Sound and Multimedia' control panel under 'Audio codecs'. Unfortunately, I don't know about any AC3 or vorbis ACM codec, only dshow filters (maybe I'm wrong?). So it's mainly useful for mp3.

vorbis acm can be found here:

authors/VA012897/

(sorry, site is japanese  but you can read the links, they're western fonts).

For ac3... well, my kx-drivers (  ) can do that, dunno for an real ACM filter though, too.

Regards,
Koepi

@dividee

Thanks for the added support for compress audio. It seems to work with virtualdub compressed mp3 audio. I tested on a sample clip which I captured with Xvid and compressed audio to mp3.

The script I used :

Import(quot;c:\avisynth\plugin.avsquot;)
vidin=OpenDMLSource(quot;e:\sample.aviquot;)
vid1=vidin.tweak(bright=23,cont=0.92)
vid2=vid1.Cnr2(mode=-1,ln=25).MergeLuma(vid1.TemporalSmoother(2,1).unfilter(0,55))
vid3=vid2.ConvertFPS(23.976,zone=48,vbi=51)
vid4=vid3.BicubicResize(640,240,-0.5,0.75)
vid5=vid4.TomsMoComp(1,-1,1)
movie=audiodub(vid5,vidin) #lt;------This is optional..seems to speed up the frame server a little for some reason...
return movie # use vid5 if audiodub is not used

The audio came out as 44.1Khz 16bit Stereo PCM

Would this AC32WAV code  be of any use in Avisynth support for AC3?

- Tom

Ah enfin ! t'as assuré sur ce coup la

Great job dividee ! I'll wait for the next avisynth binaries on sourceforge... I eager to use Cnr2 to postprocess some bad encoded movies (not by me of course  )

dividee, this truly rocks!     

I actually also had a look at it myself this weekend, but I couldn't get anything working.

I'd say, as long as it can be disabled (using the bool), it seems safe to commit it.  

While we're on the subject I think implementing floating point samples would be a great thing for Avisynth. For starters I think a simple addition of a boolean to the VideoInfo struct and some converters back and forth could do the job.  But I don't know about compatibility, and I wouldn't risk breaking anything.
I myself wouldn't mind adding float-point mode to the existing filters, and I don't know of any existing filters.

A suggestion for a more radical implementation could be:

Replacing:

Code: int audio_samples_per_second;   // 0 means no audio int num_audio_samples; bool stereo, sixteen_bit;
With something like:

Code: int audio_samples_per_second;   // 0 means no audio int num_audio_samples; int bytes_per_sample;  //Not multiplied by channels, (ie. 8,16 when using ints, 32 when using floats) int channels;  // Does it make sense to have more than 2 channels, since exporting them would be hard?
If gt;2 channels doesn't make sense, then the 'bool float_samples;' is probably the safest to use.

I don't think multiple channels do much for us.  Support for more than one audio track, OTOH, would be awesome -- too bad VDub doesn't do this.

As far as floating-point goes, I think it's a logical step forward.  The performance hit will be small since audio just ain't that much information compared with video, and the extra precision is more necessary with audio than anything else especially when you start talking about resampling (ears are very sensitive, not to mention audio encoders...)  

The best news is that there isn't a huge body of existing audio filters to change like there would be when we were talking about messing with the video formats.

Would it be safe to add quot;bool float_samplesquot; to VideoInfo?  (this _is_ a basic question I know, but I don't want to mess anything up).

Wouldn't hurt, but I like the bytes_per_sample idea better.  (quot;Int channelsquot; is a definite improvement too, even if we don't find a use for channelsgt;2 until version 50).  You can add it without worry, just don't remove the two bools until we've updated the rest of the code.