Re: [Flac-dev] Support .cda as input files

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

Re: [Flac-dev] upcoming release, need help

No problems with libFLAC here on win32. However, I'm using my own vc7.1 project file and not the one included in the distro (since only v6 and v8 files are included, not vc7.1). libFLAC compiles w/o issues and a quick smoke test revealed no problems. > checked in to CVS is what will be very clos

Re: [Flac-dev] Request for Intel build of flac on Mac OS X (with ogg)

Brian, I have put together a build for you, you can download it from http://stashbox.org/50964/flac_mac_intel.bz2 configure options used: --disable-asm-optimizations (required since gcc complained about absolute addressing) --with-ogg=/usr/local -Ben Allison > Hi folks, > > I&

[Flac-dev] MetaFLAC patch - Replay Gain support for higher sampling rates

MP3Gain CVS: http://mp3gain.cvs.sourceforge.net/mp3gain/mp3gain/gain_analysis.c?r1=1.9&r2=1.10 http://mp3gain.cvs.sourceforge.net/mp3gain/mp3gain/gain_analysis.c?r1=1.10&r2=1.11 thanks -Ben Allison Nullsoft, Inc. ___ Flac-dev mailing list Flac-dev@

Re: [Flac-dev] wav to flac corruption

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 wav

Re: [Flac-dev] Possible (bug) in winamp in_flac.dll decoder

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 ce

Re: [Flac-dev] Getting sample position

> Hello, I have problems getting sample position from libFLAC. > FLAC__stream_decoder_get_decode_position > > returns just byte position and I can't simply translate it to sample > position. > _

Re: [Flac-dev] Flac and lyrics

hat media players support 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

Re: [Flac-dev] FLAC C API / Visual Studio 2008 FILE* Issue

pts a HANDLE on Windows or an int (file descriptor) on Unix is more appropriate. -Ben Allison > I managed to get around it. I used the stream functions and provided my > own > callbacks for reading and writing. What's strange is that what I've done > is > just copied the conten

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

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 tog

Re: [Flac-dev] Idea to possibly improve flac?

> 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 fo

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

ence before Ogg 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. >

Re: [Flac-dev] Feed decoder from c++ std::stream

without sacrificing backwards 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

Re: [Flac-dev] Git branch with compiling fixes for win32

> > 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] Bug in FLAC__MD5Final?

think. 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-de

Re: [flac-dev] FLAC Mathematical Details

ow effective it would be, and certainly not optimal, but it might be faster. However, not using the potentially "grown" block in the calculation of the original LPC coefficients might reduce its effectiveness. -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] encoding complexity

s own sub-frame header for each frame. This means (potentially) that the mid channel might be of different order than the side channel. Hope that helps, -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH] Remove even more CPP hackery

> 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).

Re: [flac-dev] [PATCH] Remove even more CPP hackery

>> 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_

Re: [flac-dev] uncompressed FLAC

ith a 5400 RPM drive, or a mobile phone with a 1.2GHz ARM processor and a class-2 SD card. -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] remove src/libFLAC/ia32 permanently?

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 wrote: > Hi: > > In my opinion, we should axe all pure asm implementations

Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32

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,

Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio

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 201

Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease

ain unless 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

Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease

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.

Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease

>> * change instances of uint32_t in bitwriter.c to FLAC__uint32 > > Can we include 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 __inline

Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease

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

[flac-dev] Updated MSVC patch

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

Re: [flac-dev] Answering the Hydrogen Audio thread

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 extensions to the C libr

Re: [flac-dev] Answering the Hydrogen Audio thread

e arguments as wchar_t and converts them to UTF-8, 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. &

Re: [flac-dev] Updated MSVC patch

You can add the "pre1" in a normal text editor without risk. I didn't include those changes in the big patch you committed already. -Ben > Ben Allison wrote: > >> Erik, et al. >> >> This fixes the entire library and does it more cleanly. It puts most of

Re: [flac-dev] Updated MSVC patch

> > _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. >> &g

Re: [flac-dev] Updated MSVC patch

= 1600 || defined __BORLANDC__ /* @@@ [2G limit] */ > #ifndef fseeko > #define fseeko fseek > #ifndef fseeko > #define fseeko fseek > #endif > #endif > > Cheers, > Cristian. > > On Wed, Mar 6, 2013 at 6:24 PM, Ben Allison wrote: > >> Those checks account for compil

Re: [flac-dev] Updated MSVC patch

ms, but Visual Studio 2008 and prior represent a huge portion of developers. -Ben Allison ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] flac 1.3.0pre2 pre-release

ranslation unit. I'm surprised that this code works on other platform. It must be a bug in GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 spec for details. -Ben Allison > Hi all, > > Second and hopefully final pre-release is here: > > http://downloads

Re: [flac-dev] Updated MSVC patch

> Talking about ditching, there are still .dsp files in the repository, > these are MSVC 6 files. I haven't seen anyone on the list testing the > source with that version (MSVC 2005 was the first version to have a free > express version so this one hasn't) so these are probably broken as well. > >

Re: [flac-dev] flac 1.3.0pre2 pre-release

> 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

Re: [flac-dev] flac 1.3.0pre2 pre-release

> 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 pr

Re: [flac-dev] flac 1.3.0pre2 pre-release

>> 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 Alli

Re: [flac-dev] Higher compression modes from Flake

options that are outside the FLAC 'subset', such as larger blocksize, greater number of prediction coefficients, and higher-order Rice codes. -Ben Allison > Are you sure that the encoding library was improved, or just the > command line? > > Keep in mind that 1-8 (or 0-

Re: [flac-dev] snprintf and MS Visual Studio

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

Re: [flac-dev] flac 1.3.0pre2 pre-release

> 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 iss

Re: [flac-dev] flac 1.3.0pre2 pre-release

>> 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

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

compile libFLAC. 3) 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).

Re: [flac-dev] About Decode Streaming

The read callback can take as long as it wants (it's blocking, after all). It's almost definitely something wrong with your read callback code. Without the full source, it's hard to know exactly what. A few guesses, in no particular order. 1) Maybe you are reading in a loop and forgetting to in