View Single Post
Old 1st July 2021, 23:53   #4  |  Link
Nexin
Registered User
 
Join Date: Dec 2007
Posts: 150
Quote:
Originally Posted by LoRd_MuldeR View Post
What container format are you taling about here?
> Format AAC
> Container AVI and WAV

Quote:
Originally Posted by LoRd_MuldeR View Post
AAC streams are usually stored in MP4 container. And, as far as MP4 is concerned, the ObjectTypeIndication for "MPEG-4 Audio" is 0x40, whereas 0xFF would mean "no object type specified":
https://web.archive.org/web/20180312...rg/object.html
> This is what I assumed also but TwoCC does have FF for AAC not that many softwares support FF ID

Quote:
Originally Posted by LoRd_MuldeR View Post
But be aware that "MPEG-4 Audio" could mean any audio format from the MPEG-4 standard! So ObjectTypeIndication alone doesn't tell you the exact audio format. You have to look at AudioObjectType too. That would be 2 for LC-AAC:
https://stackoverflow.com/a/4644066

Having said that: The "classic" VirtualDub (not VirtualDub2) did not even support MP4 output, only WAV or AVI. However, storing AAC streams in WAV or AVI container is at least "unusual" and non-standard.
> Both classic and Virtualdub2 support output only AVI and WAV. There is external encoders but the ID change again to FF reason I wonder if Virtualdub at fault or the AAC_ACM codec.

Quote:
Originally Posted by LoRd_MuldeR View Post
Furthermore, the WAV/AVI container uses the "wFormatTag" field of the WAVEFORMATEX structure to indicate the audio format – which almost certainly is not related to the ObjectTypeIndication of the MP4 container
> Yes I see this with graphedit softwares WaveFormatEx always input/output even with AVS scripts. But is it really needed for 16bit 41k, 48k 2channel stereo

Quote:
Originally Posted by LoRd_MuldeR View Post
And, because WAV/AVI was never really intended to store AAC streams, there probably is no "officially correct" wFormatTag value for AAC – maybe some "de facto" standard has been established though.
> I know but a container is a container and can contain such formats. But Virtualdub2 now I suppose should know this and let audio pass unmodified. Or not change on Full Compress encode when the audio should not be touched set to Direct. I would expect ID 40 to follow through. That said the TwoCC is FF for AVI but also there is B0 NEC. I wonder why no provision for TwoCC 40.

Quote:
Originally Posted by LoRd_MuldeR View Post
To make a long story short, you may be comparing apples and oranges
> Yes maybe but the FF once written even when muxed to mp4 remains.

Quote:
Originally Posted by LoRd_MuldeR View Post
(BTW: VirtualDub2 most likely reads your input file using its FFmpeg-based input driver. This means that the audio gets decoded to PCM before it even enters the VirtualDub2 core application. That's why "Direct Stream Copy" doesn't work)

> I tried this with Import Audio from another file using different driver options. The audio ID remains FF

WavFormatEx for 16bit 41000 or 48000 kHz 2 channel stereo. I would expect not to use WavFormatEx. I see this a lot with AVS use also with graphedit. Also changes with using codec AAC_ACM to ID to FF. Tested graph direct using Monogram Muxer output to mp4. So maybe AAC_ACM changes the ID on decode.

Also with Virtualdub2 FFMpeg AAC Encoder not that I need to encode AAC again. What a mess Virtualdub2 developer made of that. Bitrate set is not the output bitrate it is way off. Audio source 128k audio convert 128k audio output 242k. Also Tag ID is again FF

So AVI WAV Tag ID FF is correct so AAC_ACM is correct.

I did dilly-dally with AVS and graphedit what a nightmare for AAC import. That is an AVISynth issue, for another day and another Topic thread.

Would be nice to have had TwoCC 40 or something 2 bit hex other than FF that all softwares see and work with.

Thanks for the learning journey that we had here. FF it is (for now)
Nexin is offline   Reply With Quote