It's been asked here in 2005, Flac changelog says (for version 1.1.3): "Large file (>2GB) support everywhere". I'm using the latest version 1.2.1 (flac.exe called from fb2k 1.0 Beta5) - Not a file system issue (Saving to an NTFS file system).

Are you sure that it is a WAV file? The WAV structure only accommodates files up to 4,294,967,294 bytes long. Sounds like the file is RIFF64 or BWF.

Hmm, I've already deleted it. I created this wave file only for testing purposes, which made my command line life easier... The original source are multiple, independent flac files, which I have merged to one 7 GB wav file... with fb2k's converter...BTW I'd also guess there's a file system/block issue here, still maybe on the flac side. The file size we are seeing is very close to 2^31 (2.147.483.648)

libFLAC uses the C stdlib for file i/o. even on my XP box with VS 2005, microsoft's stdlib implementation is still limited to 2 GB (i.e. no 64-bit off_t).

I'm reluctant to add win-specific calls to libFLAC just because MS is intentionally sabotaging portability. every other build of flac works with large files.

VS2005 and later have _fiseek64 and friends. These take an __int64. fseek is pain anyway because it's generally prototyped to take a long rather than a off_t so you need fseeko, where the size of off_t will depend on the predefines passed to the compiler, or fseeko64 which always takes an off64_t. Even getting it to work on different unicies can be a pain due to confusion over the size of off_t and the presence or lack of o64 versions of functions. I mean just look at all the crap that configure scripts test for an idea of the historical fragmentation of the unix syscall API.

There are a whole host of other reasons to write your own wrappers around CreateFile etc. For example MS cripple the standard C library calls to only deal with paths up to 254 characters long. You have to use CreateFile with a UNICODE escape sequence at the start of the file name to get 32768 characters and it comes with lots of limitations including globbing not working. How much faff to go into rather depends on how how portable you want FLAC to be? Do you need to be able to compile it on ancient versions of Solaris for example?

Basically you end up with compiler detection and preprocessor magic and wrapper functions to sort the mess out whatever you do. For example I have reams of preprocessor magic to deal with the fact that Microsoft refuse to provide support for C99 and all the new types it specifies including fixed width ones. In order to write portable code I have headers which provide all the missing types. I also have stuff to turn off the silly warnings about using "unsafe" API calls. Which is a blatant attempt by MS to get you to use their 'secure' _s replacements which are utterly non-portable.

The other thing you can do is use something like the Apache Portable Runtime to sort the mess out for you however that comes along with the baggage of a piece of code you don't control the copyright and therefore the license of and probably isn't appropriate for FLAC.

Perhaps the answer is to start a project to write a BSD licensed portability layer, I'm certainly game to help if you want to do so.

Does MinGW has this limitation? If no, maybe libFLAC compiled with MinGW is the solution to this problem.

MinGW does provide fseeko64 etc. effectively by providing wrappers around MS's C library functions. However firstly FLAC may not compile with MinGW, you have to treat it as another platform as it's a bit of a frankenmix of GNUisms and things understood by the underlying MS libraries and secondly MSVC++ almost certainly produces faster code for Windows than GCC does. However the very latest versions of GCC may have closed the gap.