search for: lrn1986

...6b4fe7ccab525cad2ceab244b8a> the current code: #ifdef _WIN32 /* * Windows can suffer quite badly from disk fragmentation. This can be * reduced significantly by setting the output buffer size to be 10MB. */ setvbuf(file, NULL, _IOFBF, 10*1024*1024); #endif LRN <lrn1986 at gmail.com> wrote: > The commit mentioned in the feature request should not cause such > behaviour, as it only does short-lived operations (opens a file, does > stuff, closes the file immediately after) and is clearly distinguishing > between disk files and pipes (which is how you...

...w.saunalahti.fi/~cse/**temp/flac-1.3pre4-win32.zip<http://www.saunalahti.fi/~cse/temp/flac-1.3pre4-win32.zip>. > I have been using the git version for my own encodes for a while now > without any issues. > > > > > ---------- Forwarded message ---------- > From: LRN <lrn1986 at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Sun, 28 Apr 2013 15:23:07 +0400 > Subject: Re: [flac-dev] Pre-release 1.3.0pre4 (hopefully the last) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28.04.2013 13:38, Erik de Castro Lopo wrote: > > I ha...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15.03.2013 12:09, Erik de Castro Lopo wrote: > Marcus Johnson wrote: >> but no matter what you choose to do FLAC MUST REMAIN LOSSLESS. > > That has always been and will remain goal #1 for FLAC. FLAC stands for Free Lossless Audio Codec, so "lossy FLAC" is like "honest politician", or "fast turtle".

...; #ifdef _WIN32 > /* > * Windows can suffer quite badly from disk fragmentation. This > can be > * reduced significantly by setting the output buffer size to be > 10MB. > */ > setvbuf(file, NULL, _IOFBF, 10*1024*1024); > #endif > > > LRN <lrn1986 at gmail.com> wrote: > >> The commit mentioned in the feature request should not cause such >> behaviour, as it only does short-lived operations (opens a file, does >> stuff, closes the file immediately after) and is clearly distinguishing >> between disk files and pip...

On Tue, Nov 26, 2013 at 10:35 PM, LRN <lrn1986 at gmail.com> wrote: > AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h > only when it's really there. > It also includes malloc.h, which is where mingw-w64 defines the > alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt > _alloca(). Thi...

lvqcl, Would you be able to have alook at this one? I think its Windows related: https://sourceforge.net/p/flac/feature-requests/114/ Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

...eplaced all the old > calls to sprintf/_snprintf. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > > > > ---------- Forwarded message ---------- > From: LRN <lrn1986 at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Mon, 18 Mar 2013 05:55:07 +0400 > Subject: Re: [flac-dev] Patch to add Unicode filename support for win32 > flac > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18.03.2013 02:10, JonY wrote: > > On 3...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h only when it's really there. It also includes malloc.h, which is where mingw-w64 defines the alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt _alloca(). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version:

On Mon, Feb 06, 2012 at 07:26:19PM +0400, lrn1986 at gmail.com wrote: > > Make a specification for storing this kind of data in app-block, then > devise a way to measure encoding complexity of existing FLAC stream - > and you'll be able to put these block in FLAC files that didn't have > them originally. What we're loo...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.02.2012 1:11, Declan Kelly wrote: > Many people who use FLAC to archive entire CDs (as opposed to > "albums" of tracks that may or may not be on the same CD) will rip > the entire disc and store it in a single FLAC file, with the CUE > sheet either as a separate file, embedded in the FLAC metadata, or > both. > >

At 14:16 06.02.2012, you wrote: >Olav, > >A change like this could easily break the format. That would be a bad choice. That makes sense. Explains why it is not there today. >On the other hand, an informational 'application' block could be added in a way that does not break the format, and this would even be backwards compatible since 'application' blocks have

In stream_decoder.c function find_metadata_() checks whether a file is valid or not. There are 4 cases it recognizes: 1) file begins with 'fLaC' 2) file begins with ID3 (skipped), followed by 'fLaC' 3) file may begin with 11111111 111110?? sync code (or 11111111111110, depends on endianess i suppose). That is - a raw file with FLAC frames, without header (right?). 4) file begins

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.02.2012 14:52, Erik de Castro Lopo wrote: > In C99, the correct way to print a uint64_t value is: > Is it wise to aim at C99? While i have absolutely nothing against it, it is a known fact that MS never got around to support C99 in MSVC to any considerable degree. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06.02.2012 18:52, Olav Sunde wrote: > At 14:16 06.02.2012, you wrote: > >> Olav, >> >> A change like this could easily break the format. That would be >> a bad choice. > > That makes sense. Explains why it is not there today. > > >> On the other hand, an informational 'application' block

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05.03.2013 20:39, Ben Allison wrote: > I would be willing to add Windows Unicode support (and large file > mode) to the flac binary tool, but frankly I'm not sure that it > could be done as a single cross-platform source file. There would > be a significant amount of either Windows API function calls or > MSVC-specific

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.03.2013 15:37, Erik de Castro Lopo wrote: > Hi all, > > Second and hopefully final pre-release is here: > > http://downloads.xiph.org/releases/flac/beta/ > src/libFLAC/metadata_iterators.c:442:4: warning: implicit declaration of function 'ftello' [-Wimplicit-function-declaration] Same with ftello, it's all over

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17.03.2013 06:33, Janne Hyv?rinen wrote: > Here's a patch that makes MSVC compiled flac.exe able to use > wildcards and encode/decode files with Unicode characters in names. > It may not be the prettiest code but it fulfills its primary > purpose. I tried to alter FLAC code as little as possible. It > replaces argv with utf-8

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18.03.2013 02:10, JonY wrote: > On 3/17/2013 23:01, LRN wrote: >>> All those ifdefs will at least be confined rather than spread >>> out through the code. >> I did it plibc-style: >> >> in compat.h: #if defined(_WIN32) #define FOPEN >> grabbag__fopen_utf8_wrapper #else #define FOPEN fopen #endif

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18.03.2013 13:35, JonY wrote: > Before anyone does anything, see __wgetmainargs > <http://msdn.microsoft.com/en-us/library/ff770599.aspx>. > > It can expand wildcards. Since it already provides argc/argv/env, > it is more a less a drop-in replacement for the main() arguments. I can't find its version info. MSDN only

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19.03.2013 20:35, Janne Hyv?rinen wrote: > > On 19.3.2013 15:49, JonY wrote: >> On 3/19/2013 19:59, Janne Hyv?rinen wrote: >>> On 18.3.2013 12:25, Erik de Castro Lopo wrote: >>>> JonY wrote: >>>> >>>>> Before anyone does anything, see __wgetmainargs >>>>>