PC is running XPsp2 on an AMD Athlon 64 Processor 3000+, 1gb RAM

The original wav file:To clarify, this is a large wav file of just over 4hrs in duration with a file size of approx 2.4gb

I used four different 'methods' of trying to encode this file into a FLAC, Ogg Vorbis & mp3 (LAME) file.

Encoding 'methods' used:
foobar v0.8.3
foobar v0.9.2b4
'drops': lamedropXPd.exe (V2.0 with 3.97b2) :: oggdropXPd.exe (1.8.9 with libvorbis 1.1.2) :: FlacDrop.exe (V1.2 with FLAC 1.1.2)
Command line running of the LAME, Ogg Vorbis & FLAC exe's.

Versions & switches used (unless where specified, i.e. oggdropXPd.):
mp3: LAME 3.97b2 :: -V2 --vbr-new
Ogg Vorbis: oggenc283_sse2_lancer20060529 :: -q4
FLAC: 1.1.2 :: --best -V

---

Results:

==== foobar 0.8.3 ====

LAME:


Ogg Vorbis:


FLAC:



==== foobar 0.9.2b4 =====

LAME:


Ogg Vorbis:


FLAC:



==== 'Drops' ====

LAME:


Ogg Vorbis:


FLAC:


==== Command Line ====

LAME:


Ogg Vorbis:


FLAC:


---

Conclusion:
foobar cannot correctly convert my file.
The 'drop' frontends and the use of the command line does work.

---

I found out all this after I'd discovered a bug with wavegain. I posted that in this thread. john33 had a look and confirmed a bug in the code citing:

the use of "signed long ints in a couple of places where they should be unsigned"
and
the use of "functions 'fseek' and 'ftell' when closing the file to ensure that any chunks that appear after the 'data' chunk are copied over, and both of these functions use signed ints!! Hence, the often seen 2GB limit!! I've circumvented this issue by using '_fseeki64' and '_ftelli64' which, as the names suggest, are similar functions, but use signed 64 bit ints. Oddly, these 64 bit functions are completely undocumented regarding their existence."

See this thread too.

---

So, I thought I'd create this looong (sorry) post in the hope of highlighting a problem presumably with foobar or foo_diskwriter / foo_converter ???

---
EDIT: meant to say 0.9.2b4 and not 0.9.4

Something similar has been discussed before.

Are you passing samples as 16bit or 24bit samples? If "highest BPS supported" is 24, try setting it to 16 for large files.

Nope, 16-bit only. Doing it at 24 fails straight away with foobar versions, with no file being created. The problem above fails part way through the convertion process, with a file created, but not at the correct length.

This is a genuine problem imo that I've reported in order for the Dev team to have a look at.

*shrug* Seemed similar to me.

Anyway, on a second look, your logs for 0.8.3 show that some files are being passed as 24bit or 32bit.

That's ok mate.

And you're right about the foobar 0.8.3 logs:
LAME: INFO (foo_clienc) : 44100Hz 24bps 2ch
Ogg Vorbis: INFO (foo_clienc) : 44100Hz 32bps 2ch

However, it is not set up like that in my foobar diskwriter preferences. I don't actually think I've ever used a greater bit depth than 16-bit. Plus, I use the same 'preference' when encoding on mass my flac CD files. So I know for sure that the settings I use do work. But seemingly on this large file they are not happy.

Lossless FLAC images are nowhere near 2 gigs in size, so I guess that's expected.

With foo_clienc or the lossy converter presets, foobar2000 passes data in the highest bitdepth that the command-line encoder can handle, AFAIK. It's not related to "Output bit depth" which only governs lossless/uncompressed bitdepth.

He's from the future!

If I use foobar to encode say a 1gb wav file into mp3 (LAME), Ogg Vorbis or FLAC, it works fine.
Using the exact same settings, it fails with the file that has originated these issues.
So surely by that rationale, foobar is having problems with this large file.

If "foobar2000 passes data in the highest bitdepth that the command-line encoder can handle" then I assume the use of the command line does NOT do that? Otherwise the command line encodes would've failed too right?

Whilst I understand more than the average joe about digital encoding, my techie knowledge is at it's limit right now. I'm failing to understand why foobar would want to up the bitdepth if the use of the same encoder at the command line does not do that (maybe I'm wrong here anyway??).

So, is there a way to adjust foobar so that the bit-depth passed in is 16-bit? I still don't get why it would increase the bit-depth when the file being passed in is only 16-bits anyway.

@prawns: ooops, I'll change it to 0.9.2b4

You are correct. The command-line encoder you invoke from the command line takes the .wav file as is, in its original 16bit form.

foobar2000 does not pass the original .wav file to the encoder, but passes it as a "bit stream," although you can tell foobar2000 to pass it as a temporary file. But then, the temporary file is not the same as the original .wav file.

The workaround to this problem would be to edit the converter presets (or make new custom ones) and limit the "highest BPS supported" to 16.

^^ ok, thanks for the info. I'll give it a go and see what happens.

By the fact you say "the workaround to this problem" implies that this is a problem with foobar though. If it's been discussed before and foobar dev decided it wasn't worth doing anything with it, then fine. If not, I'd be interested to see what they say.

Whilst I now understand why foobar errors, I just don't think it should; I'm not attempting to do anything out of the ordinary here.

thanks for the help

I was trying to give the impression that maybe the command-line encoders were to blame. I don't know the *real* problem or the real solution.

oops, ok.

I think we need some foobar devs and/or encoder devs to chip in on this thread. Anyone wanna put me right & shut me up or confirm a problem?

As you suggested kjoonlee, I've amended the 'Highest BPS mode supported' from 24 to 16 for LAME & Ogg Vorbis (I had to uncheck the 'pass floating point data' checkbox for the Ogg Vorbis preset in foobar 0.8.3). I did this in both foobar versions 0.8.3 & 0.9.2b4. I don't think I've ever amended these before, and as I said above, I've never had this issue of a file failing to be encoded by foobar before.

Anyway, here are my findings:

Results:

==== foobar 0.8.3 [take 2] ====

LAME:



Ogg Vorbis:



---

==== foobar 0.9.2b4 [take 2] ====

LAME:




Ogg Vorbis:



I didn't need to run FLAC again as it's setting was already at 16.

So there still seems to be a problem. And all the files now fail at 3hrs 22mins 53secs: not sure why that is??? However, that was also the same time that the file failed with wavegain 1.2.6.

There's still a problem here me thinks. Can anyone else confirm this? Any fb2k Dev wanna take a look at this?

Cheers

jaybeee

Uncompressed 44.1kHz 16bit stereo files have a bitrate of 1411200bps, or 176400bytes per second.

3 hours 22 minutes 52 seconds mean 12172 seconds.

Multiply the bitrate with the approximate playtime and you get the approximage stream size, which is around 2147140800.

This looks dangerously close to 2147483647, 2 gigs.

Programs *should* be able to handle 4 gigs on 32bit architectures, but they usually can't.

http://www.hydrogenaudio.org/forums/index....showtopic=32422

Yep, I know that

But is that simply enough for foobar? Is foobar gonna be constrained by that? If so, fair enough, but a response from fb2k dev would be nice, that's all.

I'm only ytrying to be helpful and report a 'bug' I found

From the thread linked by kjoonlee.
If this is a 'bug' in foobar OR the commandline encoders then there seems to be no reason why it cannot be corrected.

Offtopic: I finally used the multiquote toggle correctly for the first time.

There's another thread at the Vorbis forums: not possible to encode a 3.5GB wave file.

jaybeee, could you please check if using "oggenc < in.wav" like in the thread above works for 3gig files?