With reference to this thread, I believe there might be a problem with foo_ac3.

In the 2nd post of the linked thread, I mentioned that I repeated my test on another PC and had no problems. However, I recently had the chance to test with a 3rd PC and encountered the problem mentioned in my first post. The most obvious similarity between the 2 affected PCs is that they both use Intel's 945G chipset.

I have tried this with both 2 and 6 channels AC3 files, and both tests yield the same problem. Additionally, as mentioned previously, I don't face this problem with MP3 or FLAC files, leading me to believe the problem lies with foo_ac3.

Another possibly related problem is when I transcode AC3 files. When batch transcoding an album, some tracks have sudden 'spikes'. Trying this a few times, I noticed that the 'spikes' occur at seemingly random positions. Thus I am guessing that the problem I have (ReplayGaining AC3 files as albums) is related to these spikes i.e. ReplayGain fails for a certain track when foo_ac3 somehow renders a 'spike' as output.

For a sample of this 'spike', please see this upload.

An update that might hopefully solve this problem: I managed to dig out old versions of foobar2000 (0.8.3) and foo_ac3 (0.6) and tried it out. Result: No problems whatsoever, be it decoding to WAV (no 'spikes') or ReplayGaining.

Could be driver related. Even if it does work with previous versions of foobar

Are you suggesting the chipset or sound card driver? I would think chipset? Because I doubt the decoding process goes through the sound card. Either way, I can't seem to locate an updated driver for my chipset nor sound card.

In addition, I've also tried Azid and have no problems as well.

I understand it's hard to pin-point this problem as it cannot be reproduced across different PCs. Ah well, guess I will rely on foobar2000 0.8.3 and foo_ac3 0.6 for this purpose then.

Thanks for your help.

This may be related to the djbfft support that I enabled in a52dec a few months ago. I have uploaded a new build with djbfft disabled and removed from the build process, since it has no measurable effect on performance, and probably introduced some problems in the way of mixing compilers, since I had to build it with gcc.

Thanks for your reply kode54, really appreciate your help here.

Tried the new build, but the problem persists. Any chance you could help me with a compile of foo_ac3 0.6 for foobar2000 0.9.x? To see if it's really foo_ac3 that's causing the problem?

I also have random "skips" in songs, and Replaygain scanning sometimes fails for albums in AC3. The uploaded new version does not fix this.

Borisz, just curious, are you using Intel's 945G chipset as well?

Sound Blaster Live! 5.1, using KXproject drivers and Kernel Streaming. Nvidia nForce3 chipset in my mobo.

I don't remember if I experienced the same bug in Foobar 0.83, but it has been too long ago since I used that.

If all else fails, try multiplexing the files into Matroska container with mkvmerge or similar and run the result through the Matroska input with my component loaded. That should rule out any errors with the bitstream parser.

Tried your suggestion and got the same problem when ReplayGaining the resulting .mkv file. Does this mean the bitstream parser is erroneous?

Managed to narrow down the problem some more. Basically, I got things working as expected by disabling multi-core support for my Intel 945G motherboard (via BIOS), which uses Intel Core Duo processor.

Hope this helps the debugging.

Edit: Was searching the forum and came across this post, stating that multi-processor support was introduced only in foobar2000 0.9.x onwards. Is this why the problem does not occur in fb2k 0.8.3?

Seems like you found the source of the problem. I also run a dual core cpu and experience the same bugs.

But after using the Task Manager to set Foobar to use 1 cpu only, I got no errors in the Replaygain process. I even tried RGing multiple times, but got no problems now.