On Mar 4, 2013, at 14:39, Timothy B. Terriberry wrote:
> 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
On Mar 4, 2013, at 20:03, nu774 wrote:
> (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 inclu
On Mar 4, 2013, at 22:50, Erik de Castro Lopo wrote:
> nu774 wrote:
>> (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
>
Brian Willoughby wrote:
> I do not see the need to jump to 64-bit merely to get beyond the 2 GB
> limit. There are modern API that handle 32-bit unsigned file lengths
> - i.e., up to 4 GB - without going to 64-bit.
When we are talking about offset_t we are talking about the flac C and
C++ API
On 06-03-13 09:43, Brian Willoughby wrote:
> 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 size.
I agree it's ugly, but if you take a look at the FLAC bug tracker or the
thread on HydrogenAudio that has be
Brian Willoughby wrote:
> That's an awful "solution" waiting for errors to be introduced into
> what might otherwise be valid files.
I agree that this solution is non-optimal, but it is a a solution
that works in most cases where the file is over 4 Gig. Furthermore,
its optional; you have to ex
Erik de Castro Lopo wrote:
> LRN wrote:
>
> > I've sent a utf-8 support patch to flac-dev, but it didn't arrive. The
> > patch file is around 64k, so i believe that this is the problem. Maybe
> > i should compress it?
>
> Maybe send it directly to me, erikd at my usual domain name.
I have LRN's
On Mar 6, 2013, at 00:55, Erik de Castro Lopo wrote:
> Brian Willoughby wrote:
>
>> I do not see the need to jump to 64-bit merely to get beyond the 2 GB
>> limit. There are modern API that handle 32-bit unsigned file lengths
>> - i.e., up to 4 GB - without going to 64-bit.
>
> When we are talking
Brian Willoughby wrote:
> What about fseeko()? I use that in my ObjC library for converting
> between AIFF, FLAC, and WAVE. It takes an unsigned 32-bit offset, as
> contrasted with fseek() classic. Unless you need negative offsets,
> that seems like a simple change.
>
> FLAC__stream_decoder
Will you guys ever shut down or start using the Sourceforge page? It's
pretty confusing for newbz.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
(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
Ben Allison wrote:
> Erik, et al.
>
> This fixes the entire library and does it more cleanly. It puts most of
> the guts into share/compat.h
Thanks Ben.
I applied a slightly tweaked version of the patch. The patch had to be
tweaked because it broke the Linux build :-). Specifically, the file
i
Marcus Johnson wrote:
> Will you guys ever shut down or start using the Sourceforge page? It's
> pretty confusing for newbz.
There was some discussion of this a while back. Yes, we'd like to shut
down the sf.net page.
Erik
--
-
Thanks, Erik.
This is the delta that should fix everything up.
I hope that #include "share/compat.h" is acceptable from the test_streams
binary. If not, you can probably change it to FLAC/ordinals.h instead
Also don't forget to commit my earlier VERSION="1.3.0" patch. You can add
the "pre1" in
Hi Ben,
Can you please remove the _MSC_VER >= 1600 check?
_MSC_VER 1600 is set for Visual Studio 2010, which means
that Visual Studio 2012 will get a lot of errors because _MSC_VER
is defined as 1700.
Cheers,
Cristian.
On Wed, Mar 6, 2013 at 5:53 PM, Ben Allison wrote:
> Thanks, Erik.
>
> Thi
Those checks account for compiler changes/improvements introduced in
Visual Studio 2010 that are not present in Visual Studio 2008.
I will grab Visual Studio 2012 off of MSDN and make sure everything is OK
there.
-Ben
> Hi Ben,
>
> Can you please remove the _MSC_VER >= 1600 check?
>
> _MSC_VER 1
Great.
I need to correct my statement, the check for _MSC_VER <= 1600
was the culprit, like this case:
#if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
#include /* for off_t */
#if _MSC_VER <= 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
#ifndef fseeko
#define fseeko fsee
This should be enough to fix it
> Great.
>
> I need to correct my statement, the check for _MSC_VER <= 1600
> was the culprit, like this case:
>
> #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
> #include /* for off_t */
> #if _MSC_VER <= 1600 || defined __BORLANDC__ /* @@@ [
18 matches
Mail list logo
