On 04-03-13 23:19, Erik de Castro Lopo wrote:> Link please?http://www.hydrogenaudio.org/forums/index.php?showtopic=99757> Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig. > > Also, the link in that post contains a flac windows binary which is not > of much use.It seems Case hasn't released any source, but the other posts in the thread state what changes have been made to get to this.
On 3/4/2013 11:26 PM, Martijn van Beurden wrote:> On 04-03-13 23:19, Erik de Castro Lopo wrote: >> Link please? > http://www.hydrogenaudio.org/forums/index.php?showtopic=99757 > >> Err, thats a link to a post talking about flac's WAV reader being limited >> to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. >> Due to limitations in the way WAV files are specified, no valid WAV file >> can ever be over 4Gig. >> >> Also, the link in that post contains a flac windows binary which is not >> of much use. > It seems Case hasn't released any source, but the other posts in the > thread state what changes have been made to get to this. > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-devThis is an older issue reported in 2007: http://lists.xiph.org/pipermail/flac-dev/2007-September/002423.html The fix would be to use _ftelli64 instead of ftell with Visual Studio. http://msdn.microsoft.com/en-us/library/0ys3hc0b%28v=vs.110%29.aspx Cheers, Cristian.
> This is an older issue reported in 2007: > http://lists.xiph.org/pipermail/flac-dev/2007-September/002423.html > > The fix would be to use _ftelli64 instead of ftell with Visual Studio. > http://msdn.microsoft.com/en-us/library/0ys3hc0b%28v=vs.110%29.aspxThat's not enough. At least, the followings are also needed. 1. Change off_t to something else. off_t can lead to ABI issue when used in public API, since it's definition can change even on the same system (by setting _FILE_OFFSET_BITS or something), and is always 32bit on mingw, mingw-w64 and MSVC. Since FLAC even takes the trouble of casting seek offset to off_t when calling fseeko(), it gets truncated to 32bit on Win32 even if you use _fseeki64(). This change results in ABI break, but luckily it seems there's only one metadata function that uses off_t in public API. 2. i686-pc-mingw also needs fseeko()/ftello() definitions (only fseeko64() and ftello64() available). 3. stat()/fstat() must be also taken care of, when it is used to get file size. 4. In some place, size of off_t is checked to see if FLAC binary is compiled with large file support. These also need modification. I have made a fork on https://github.com/nu774/FLAC including these patches, but it's not tested enough. Erik already knows at least off_t issue, and he said he'd like to fix it in the future. It needs many lines of change (although it basically is a trivial replacement).