) For Windows C runtime libraries that are missing 64-bit seek/tell, we
can fall back to ftell and fseek and encourage those developers to use
FLAC__stream_decoder_init_stream instead. This is also the correct way
for developers to use platform-specific I/O (CreateFile, etc).
-Ben Allison
Janne
Jaren Stangret wrote:
Testing the metadata-handling properties of flac-to-flac encoding...
case00a... Files case00a-expect.meta and out.meta differ
ERROR: metadata does not match expected case00a-expect.meta
make: *** [fullcheck] Error 1
Last night I did a git bisect on this issue and this
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
Ben Allison wrote:
As mentioned before, this removes some of the 'inline' from the
bitreader
and bitwriter functions that were used in another translation unit.
I'm
surprised that this code works on other platform. It must be a bug in
GCC, or maybe deliberately non-standard behavior
On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
From 6.7.4.6
An inline definition does not provide an external definition for the
function, and does not forbid an external definition in another
translation unit. An inline definition provides an alternative to an
external
On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote:
I will redo the patch with these 'extern' function definitions defined
inside the corresponding .c files.
As promised, here is the patch to declare the inline functions as external
definitions.
-Ben Allison
FLAC-1-3-0-inline
Erik, et al.
This fixes the entire library and does it more cleanly. It puts most of
the guts into share/compat.h
-Ben Allison
flac-1-3-0-MSVC.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman
, and has
replacement functions for fopen and some text output that accept UTF-8
instead of ANSI. I think it automatically kicks in on definition of
WIN32, or something like that. Worth a look, at least as a base
implementation.
On Tue, 5 Mar 2013 11:39:19 -0500
Ben Allison ben...@winamp.com wrote
Here's another go at it. I only have VS2008 and VS2010 to test with right
now. VS6.0, VS2003 and VS2005 are untested.
I'm still not too happy with it, but it does work.
I would recommend using FLAC__uint32 instead of uint32_t to avoid these
small #if _MSC_VER things everywhere, although
one of the principal developers is using
it on a daily basis (as I know you've experienced with libsndfile, Erik).
-Ben Allison
Johnny Rosenberg wrote:
Maybe a stupid question, but I was born stupid and I have walked that
path ever since, so: Is there a changelog?
The only changelog
There's a more few issues for compiling on MSVC. I put together a patch.
Here's a quick rundown:
* must use __inline keyword with static inline functions (bitmath.h)
* change instances of uint32_t in bitwriter.c to FLAC__uint32
* functions marked inline cannot be used within another C file (e.g.
* change instances of uint32_t in bitwriter.c to FLAC__uint32
Can we include inttypes.h to fix this instead?
Sadly there is no inttypes.h on MSVC. At least versions to Visual Studio
2010. I presume this is why ordinal.h was created in the first place.
I'll use the compat.h header for the
Are you calling
FLAC__stream_encoder_finish(encoder);
before you call
FLAC__stream_encoder_delete(encoder);
That would cause this issue.
-Ben Allison
I'm using libflac on Windows to compress some audio samples. I'm building
the
library locally, using Visual Studio 2010. Each set of data is 2
Largest risks are:
1) encoding errors in a scenario not exercised by the tests
2) violations of the spec that are tolerated by the decoder. I've seen this
before with, e.g. x264, where a bug is repeated in the encoder and decoder and
hence not caught by any tests.
On Apr 26, 2012, at 2:49 AM,
No. It is much faster, measurably. Anyone who believes the old adage that
compilers outperform humans isn't writing math code or is just a lousy assembly
programmer.
On Apr 12, 2012, at 9:32 PM, Cristian RodrÃguez crrodrig...@opensuse.org
wrote:
Hi:
In my opinion, we should axe all
that, for some devices,
decoding FLAC is actually faster and less resource intensive than WAV
because the reduced I/O cost outweighs the CPU cost. This would be
espcially true in a fast laptop with a 5400 RPM drive, or a mobile phone
with a 1.2GHz ARM processor and a class-2 SD card.
-Ben Allison
Dave Yeo wrote:
Yes that makes sense. Requiring a C99 compliant compiler seems quite
reasonable.
Well I'm actually going to be even more reasonable than that. The only
bits of C99 that flac will really require is header file
with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik
. I'm not even sure the
purpose of this. It appears to be for zeroing out the passed in data
structure, but it's only zeroing out the first 4 bytes (or 8 on 64bit platforms)
-Ben Allison
Nullsoft, Inc.
___
flac-dev mailing list
flac-dev@xiph.org
http
Development is probably complete. Maintenance should continue.
Speaking of which, I plan on starting AMD64, ARMv5, and ARMv7 assembly
routines in the next few weeks. I'll sync up with Erik on getting them
integrated.
-Ben Allison
___
Flac-dev
compatibility with existing versions
of libFLAC (and compatibility with software and devices that have
integrated it).
-Ben Allison
Well, unless somebody has a brilliant idea, I am giving up on this. I
don't see how I can do what I wanted to. The slightly hacky way I thought
would work
The issue is that silent frames compress to a very small size, and the Ogg
packeting layer can put more than one FLAC frame into a page. So if you
have an extended period of silence with a live or rate-limited input
stream, the client buffers may exhaust themselves before a new page can be
put
The whole picture is a bit inconsistent. If Flake is only an
encoder, and compression levels above 8 are not guaranteed to be
compatible, then what's the purpose? If Flake cannot decode, then
what good is it to create a file that no other decoder can handle?
Compression levels above 8 for
decided to
send another page out over the network.
If the input audio on the server is coming from a live-source (such as
simulcast of an FM station) or if the disk I/O is very slow, this can be
extremely problematic.
Ben Allison
Principal Software Engineer
Nullsoft, Inc.
I just thought
this combination (and if
the ones that do support it will also support lyrics)
-Ben Allison
FLAC supports Application-specific metadata blocks. Although I am
not aware of any which are specific to lyrics, you could create your
own. If nothing exists, and you were to make a proposal for review
Hello, I have problems getting sample position from libFLAC.
FLAC__stream_decoder_get_decode_position
http://flac.sourceforge.net/api/group__flac__stream__decoder.html#ga35
returns just byte position and I can't simply translate it to sample
position.
He's reporting a bug in the older/outdated Winamp plugin included with FLAC.
http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/plugin_winamp2/
I don't think anybody is maintaining this plugin anymore, as there is
little need; there is a better plugin included with Winamp.
However, I'm fairly
Winamp supports 24bit FLAC files just fine. Make sure you are using the
plugin that ships with the latest versions of Winamp, and not the one
distributed with the FLAC tools.
Justin Waddell wrote:
I have exactly the same problem.
I encoded a BWF file to flac and then then decoded back to
CDA is not a file format. It's just a shortcut in windows. CD
Ripping requires device-level SCSI communications via the Device Driver
API (DeviceIoControl) and is way out of the scope of FLAC. Use Exact
Audio Copy or another ripping program to do this.
Daniel Aleksandersen wrote:
Hi list,
28 matches
Mail list logo
