(2013/03/06 17:43), Brian Willoughby wrote:
> That's an awful "solution" waiting for errors to be introduced into
> what might otherwise be valid files.
>
> There is no way for a RIFF/WAVE to exceed 4 GB because all chunks
> must be enclosed within a global chunk, which is limited to a 32-bit
> si
chronization for multithreading is not
required.
Actually I also have written such kind of wrapper for fdkaac frontend:
https://github.com/nu774/fdkaac/blob/master/src/compat_win32.c
IIRC opustool just sets UTF-8 codepage(65001) via SetConsoleCP() and
directly printf'ing to console with UTF8
(2013/03/05 12:27), Cristian RodrÃguez wrote:
> Nothing against you code, that's ugly ..but as it is a first step it can
> be forgiven :-)
>
> I will just force flac to be built with 64 bit file offsets and just
> reject any caller trying to include/link libflac into a non-lfs program
> like
>
> ht
(2013/03/05 7:19), Erik de Castro Lopo wrote:
> 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
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).
Hi,
This patch addresses the following issue:
[Problem]
MinGW build of flac command fails to parse piped WAV input with
WAVEFORMATEXTENSIBLE format.
[Description]
This is because MinGW fseeko() doesn't return error for the attempt to
seek on non seekable file (same behavior as MSVC).
The simplest
