fact chunk versus length calculation -Sound Forge - PC

Subject:fact chunk versus length calculation Posted by: wwscrispin Date:1/28/2004 1:04:20 PM I have a wave file that is compressed 9-1 over PCM (proprietary CELP based compression) and in the header the wBitsPerSample are set to zero. When I load this into SoundForge 6 or 7 then total number of samples are 10X greater than the actual amount of data and a tail of data near the end of the real file is replicated over and over to fill the space. If I go to Options->Preferences->General->Ignore Fact Chunk when opening compressed WAVE files and uncheck this everything works okay. I understand why everything works okay when I do this because I have created a correct "fact" chunk when I write this audio into a wave file. What I want to understand is how does SoundForge calculate the length of the file when it does not use the "fact" chunk.
Subject:RE: fact chunk versus length calculation Reply by: SonyTSW Date:1/28/2004 9:18:51 PM >What I want to understand is how does SoundForge calculate the length of the file when it does not use the "fact" chunk. It queries the Windows Audio Compression Manager (ACM) for the length, which uses information from the audio codec to determine this value. However, this length is only an estimation of the size and it errs on the side of being too large. For some formats it is quite accurate. Apparently for your proprietary CELP codec, it is grossly incorrect. As a result, you're seeing a lot of extra "garbage" at the end of your audio.
Subject:RE: fact chunk versus length calculation Reply by: wwscrispin Date:1/29/2004 7:53:00 AM Ahh, that was very informative. I was thinking it was doing something from the wave format in the header but no matter how I juggled the numbers I could not get the same ones as SoundForge. It is probably too much to ask but if you could determine which ACM calls are used it would help me debug any problems with this CODEC and report it back to the vendor. Is it acmStreamSize()? SoundForge is the only one of my three sound editing packages that gets it so far off and I want to be able to show to the vendor what they need to clean up in their ACM implementation. Thanks again for the helpful and detailed response.
Subject:RE: fact chunk versus length calculation Reply by: SonyTSW Date:1/29/2004 8:41:08 PM Yes, that's the ACM call. It is important that this length estimation returned by a codec can never be too small (compared to the actual length if the audio was decoded). An application can rely on this for allocating memory needed for storing the decoded data. So it is possible they are using a best-case assumption in the computation of the length value (i.e. the highest compression ratio mathematically possible was achieved). Depending on the algorithms used, it may be extremely difficult if not impossible to determine the length more accurately without actually decoding the audio stream. Perhaps some of those other sound editors decode the stream first to determine the length? With very small files this may not be noticeable (unless the decoding is CPU-intensive). Or an application might be doing some length estimation on its own, by having the codec decode a portion of the audio and applying that compression ratio to compute the expected length.

Subject:fact chunk versus length calculation

Posted by: wwscrispin

Date:1/28/2004 1:04:20 PM

I have a wave file that is compressed 9-1 over PCM (proprietary CELP based compression) and in the header the wBitsPerSample are set to zero.

When I load this into SoundForge 6 or 7 then total number of samples are 10X greater than the actual amount of data and a tail of data near the end of the real file is replicated over and over to fill the space.

If I go to Options->Preferences->General->Ignore Fact Chunk when opening compressed WAVE files and uncheck this everything works okay.

I understand why everything works okay when I do this because I have created a correct "fact" chunk when I write this audio into a wave file.

What I want to understand is how does SoundForge calculate the length of the file when it does not use the "fact" chunk.

Subject:RE: fact chunk versus length calculation

Reply by: SonyTSW

Date:1/28/2004 9:18:51 PM

>What I want to understand is how does SoundForge calculate the length of the file when it does not use the "fact" chunk.

It queries the Windows Audio Compression Manager (ACM) for the length, which uses information from the audio codec to determine this value.

However, this length is only an estimation of the size and it errs on the side of being too large. For some formats it is quite accurate. Apparently for your proprietary CELP codec, it is grossly incorrect. As a result, you're seeing a lot of extra "garbage" at the end of your audio.

Subject:RE: fact chunk versus length calculation

Reply by: wwscrispin

Date:1/29/2004 7:53:00 AM

Ahh, that was very informative. I was thinking it was doing something from the wave format in the header but no matter how I juggled the numbers I could not get the same ones as SoundForge.

It is probably too much to ask but if you could determine which ACM calls are used it would help me debug any problems with this CODEC and report it back to the vendor. Is it acmStreamSize()?

SoundForge is the only one of my three sound editing packages that gets it so far off and I want to be able to show to the vendor what they need to clean up in their ACM implementation.

Thanks again for the helpful and detailed response.

Subject:RE: fact chunk versus length calculation

Reply by: SonyTSW

Date:1/29/2004 8:41:08 PM

Yes, that's the ACM call.

It is important that this length estimation returned by a codec can never be too small (compared to the actual length if the audio was decoded). An application can rely on this for allocating memory needed for storing the decoded data.

So it is possible they are using a best-case assumption in the computation of the length value (i.e. the highest compression ratio mathematically possible was achieved). Depending on the algorithms used, it may be extremely difficult if not impossible to determine the length more accurately without actually decoding the audio stream.

Perhaps some of those other sound editors decode the stream first to determine the length? With very small files this may not be noticeable (unless the decoding is CPU-intensive). Or an application might be doing some length estimation on its own, by having the codec decode a portion of the audio and applying that compression ratio to compute the expected length.