I tried to encode an AC3 (a sound file from a movie) to Ogg Vorbis (in order to mux this audio into an XviD backup), and foobar said that encoding failed (the file was at 100% of encoding, and when I loaded it in the playlist, the timing was the same as the original AC3).



Can someone please tell me where the error is and how to correct it?
Thank you.

I have the same problem. I thought that a "generic compile" solved the issue, but I encountered it several time this month on two different computer and two different compiles.
If you have temporary space enough, decode all AC3 to wav first and then use OggDropXPd.

Yes, I will probably do that, although OggDropXPd doesn't give me all the options I need. I'll try something like this though.

Anyone else got any ideas?
Many thanks.

edit: I think I solved it... I believe the box "Pass floating point data" has to be ticked. I'll go now and do some more testing. If it doesn't solve it, I'll edit this post again =]

For me unticking the box "Pass floating point data" solved the problem (I used 24 bit, didn't try 32).

Funny enough, when I had this error on 2 movies (before i read this thread) and when I checked the produced files, they were valid and both had a length of 1hr 33 min and 12 seconds. Maybe this could ring a bell for anyone?

The default setting work for me...
i use oggenc2 2.6 or 2.8 AoTuv4.5.1 with Q4
("Pass floating point data" is ticked by default)

But i found some audio artifact/wrong channel order problem when decode with fb2k 0.8.3 and ffdshow + haali media splitter, the music sound "corrupted or collapsed"...
Tested with 2 5.1 ac3 audio file, i forgot where is the link to download the free ac3 audio file.(im not sure its legal or not)

All versions of oggenc2/oggdropXPd prior to the latest versions will probably fail because they did not recognise the WAVEFORMATEXTENSIBLE header format. The latest versions recognise this correctly and will map the channels to the vorbis I spec requirements using the channel mask. I am assuming that foobar will generate the correct header when decoding the AC3.

@john33:
Im using oggenc2.8-aoTuVb4.51P4 from rarewares.org, to encode 5.1 ac3, but i still have problem when playing the 5.1 ogg vorbis fb2k 0.8.3 even 0.9 beta 13 version.

Here is the link to download the 5.1 ogg vorbis encode by the lastest oggenc with -q 0.
http://www.geocities.com/y0ngc/2.8Bjorn_Ly...urround-001.zip

The problem is same as my previous post described.

I might be wrong, i use fb2k bitcompare tracks to compare with 2.6 and 2.8 oggenc version encoded file,
and... fb2k tell me this 2 tracks are bit-identical...
Windows reported 2 files size are same.

Sorry, but it's still not clear to me how the decode of the AC3 proceeds thru foobar. If the decoded data is passed without remapping the channels, then it should be encoded correctly as vorbis uses the same channel mapping as AC3. If the channels are remapped for correct wave output then, without the header, they will not be mapped correctly by the encoder and will be encoded in the order presented. This will cause the corresponding problem on decode of the vorbis stream.

Also, without knowing whether the players are handling the multi channel vorbis streams correctly, it is a little difficult to answer this. The ogg vorbis encoders have always handled multi channel (upto 255 channels) audio, but have not previously mapped the channels correctly.

@john33:
thx for the replies
Just now i tried decode the ac3 to 6 ch wav file, then encode it with latest oggdropxpd, those problems are gone.
As you said, fb2k might have some problem with multichannel audio(im investigating the problem now)...

I kept on my laptop an AC3 file impossible for me to encode with foobar2000 and any oggenc.exe compile or version. I've just downloaded the latest oggenc 2.8 genericcompiles on rarewares.
The source is 2h14'57'' long and correspond to a 384 kbps mono but 2.0 encoding.

Summary

=> I can't encode this file with foobar2000 and/or oggenc. Using stdin or not doesn't change anything. The use of "pass floating point data" change the behavior: without this option the encoding always stops at 2h04'16'' and with this option checked the process always ends at 1h33'12'' (exactly what StephanV noticed yesterday).

Then I tried to use directly oggenc.exe in a "cmd" window. Source is a WAV file (AC3 decoded with foobar2000)


=> no problem. oggenc2.exe is working fine here and therefore only fail when it's associated with foobar2000 0.83.

Finally, I tried with foobar2000 0.9 beta with the same WAV file as source but I can't manually change the encoder location (once the oggenc's directory is specified, you can't apparently configure a new one). The test is not possible.

Maybe I must add that I'm not creating a multichannel Vorbis: I'm downmixing the audio to stereo using foobar's internal plugin. I use q0 as encoding setting.

OggEnc (through foobar) crashed for me too, when trying to encode a 5.1ch AC3 soundtrack to 6ch Vorbis.

Tried encoding several times, using different builds and versions of OggEnc2. The crash would always happen at the same point in the audio stream.

I will try again right now without "pass floating point data (some encoders only)".

After a few encoding attempts were done, I must say the following:

On some AC3 sources, Vorbis encoder will crash if "pass floating point data" turned on, while on others it will crashed if this is turned off.
All AC3 sources I used were 5.1.

Accidentally discovered that, so I didn't actually write anything down. Would anyone like me to take a few samples and upload them here?

It's good to see that someone took the time to fix that . Have you guys mentioned this problem over on the FB2K forums by any chance? First of all what is the bit-packed type on each AC3 files did you guys ever think about that? Without knowing the specifics of the problem are you passing 16-bit unsigned int samples here or are they floating point samples? that could be the cause of the problem. Try and keep in mind the encoder is not "tuned" properly for multi-channel files also.

http://www.microsoft.com/whdc/device/audio...haud.mspx#ENLAC

Hmm... I am going to have to read this after.