Hi all,
There are a bunch of sprintf calls in the FLAC code base and I'd like
to replace them with calls to snprintf but I know that can cause
problems with at least some versions of Visual Studio.
Whats the current state of play in this regard?
Erik
--
-
Janne Hyvärinen wrote:
> The patch was made from the published pre2 version. It missed the MinGW
> changes that were applied to git version.
Patch applied. Thanks.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
_
On 3/14/2013 8:00 AM, Erik de Castro Lopo wrote:
> Hi all,
>
> There are a bunch of sprintf calls in the FLAC code base and I'd like
> to replace them with calls to snprintf but I know that can cause
> problems with at least some versions of Visual Studio.
>
> Whats the current state of play in thi
Speaking of better compression, I've been using the following options on
the command line for ages. I'm not sure what they actually do (stole the
recipe from a thread on this mailing list, if I remember right), but they
seem to improve the compression ratio over just using --best (by 0.3 to
0.5% ty
On 14.3.2013 9:37, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
The patch was made from the published pre2 version. It missed the MinGW
changes that were applied to git version.
Patch applied. Thanks.
Erik
Unfortunately with this commit the LRN's patch from commit
b85cc57d73a286a07e5
On Wed, Mar 13, 2013 at 10:06:51PM -0400, ben...@winamp.com wrote:
>
> Flake is a completely independent codebase. When I used it years ago, I
> remember it being not only better compression but significantly faster as
> well. I believe some of the techniques used in libflake were added to
> lib
On 14-03-13 20:02, Declan Kelly wrote:
> The next official release of the FLAC command line should really have
> a "-9" option for absolute maxed-out big-memory CPU-burning compression.
No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even
LA, you'll lose hardware compatibility
Ühel kenal päeval (neljapäev, 14. märts 2013 19:02:35) kirjutas Declan Kelly:
> On Wed, Mar 13, 2013 at 10:06:51PM -0400, ben...@winamp.com wrote:
> > Flake is a completely independent codebase. When I used it years ago, I
> > remember it being not only better compression but significantly faster
On 14-03-13 20:16, Marko Uibo wrote:
> One possibility is to broaden Flac subset. But I don't know is it good
> idea or not.
It's not a good idea, except when you want to ruin FLACs reputation. One
of the reasons FLAC is (alongside ALAC) one of the two most popular
lossless codecs is because of
On Thu, Mar 14, 2013 at 08:12:14PM +0100, mva...@gmail.com wrote:
> No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even
> LA, you'll lose hardware compatibility anyway and they do much better
> than FLAC will with a -9 option.
No. I want the tightest possible compression, wh
On Thu, Mar 14, 2013 at 08:31:34PM +0100, mva...@gmail.com wrote:
> It's not a good idea, except when you want to ruin FLACs reputation. One
> of the reasons FLAC is (alongside ALAC) one of the two most popular
> lossless codecs is because of the well-defined subset. I've tried Flake
> -9, -10,
Janne Hyvärinen wrote:
>
> On 14.3.2013 9:37, Erik de Castro Lopo wrote:
> > Janne Hyvärinen wrote:
> >
> >> The patch was made from the published pre2 version. It missed the MinGW
> >> changes that were applied to git version.
> > Patch applied. Thanks.
> >
> > Erik
>
> Unfortunately with this
On 14-03-13 21:24, Declan Kelly wrote:
> No. I want the tightest possible compression, while remaining 100%
> compatible with the subset that all known FLAC decoders can successfully
> stream or play now in cars, Hi-Fi units, "MP3 players" and cell phones.
> The out and out most widely supported lo
Ühel kenal päeval (neljapäev, 14. märts 2013 22:06:02) kirjutas Martijn van
Beurden:
> On 14-03-13 21:24, Declan Kelly wrote:
> > No. I want the tightest possible compression, while remaining 100%
> > compatible with the subset that all known FLAC decoders can successfully
> > stream or play now i
Hi,
On 03/14/2013 03:31 PM, Martijn van Beurden wrote:
> On 14-03-13 20:16, Marko Uibo wrote:
>> One possibility is to broaden Flac subset. But I don't know is it good
>> idea or not.
>
> It's not a good idea, except when you want to ruin FLACs reputation. One
> of the reasons FLAC is (alongsid
Christoph Terasa wrote:
> Since MS refuses to support C99, the common practice is to use either
>
> sprintf_s:
> http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx
> _snprintf_s:
> http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx
>
> The former can be used as
Microsoft provides a surprisingly good (but proprietary) API inside strsafe.h.
StringCchPrintfA can be substituted for snprintf but the return value is
different. A small wrapper function around StringCchPrintfExA could get you
enough information to emulate snprintf well. But sprintf_s might
Ben Allison wrote:
> Microsoft provides a surprisingly good (but proprietary) API inside
> strsafe.h.
All of which are completely useless from cross platform code. I remember
looking at that stuff at some time and thinking that their API design
was somewhat lacking in clarity or vision (to be gen
18 matches
Mail list logo