Re: [Flac-dev] Can a libFLAC encoder be initialize and called from inside a libFLAC decoder callback?
On Tue, May 24, 2011 at 3:11 PM, David Troendle da...@troendle.org wrote: Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the FIFO, and will probably go in that direction. What do you think of implementing the FIFO via a pipe? That might simplify the implementation. Pipes on *nix systems are generally not very big, so be careful. Historically they were limited to about 5kB. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On Mon, May 23, 2011 at 2:35 PM, Dennis Brunnenmeyer denn...@chronometrics.com wrote: I'm well aware how compression works. If you're going to be condescending, then it only to remains to say that you're clearly not aware of how compression works. But images and document files do not depend on the relative timing of the data to reproduce themselves. They are in essence only two-dimensional in space, whereas the data in a sound file is time-dependent. This is a complete misunderstanding. The question really has more to do with the decoded FLAC stream output, which I presume is a linear PCM file, e.g. WAV. If FLAC is lossless and created from an original CBR WAV file, is is true that the decoded output is also CBR when played? FLAC is a lossless compression scheme. That's it. Stop wondering, and if you can't stop wondering, go read the papers on it. Thanks for any insights on this matter. I've been told that because a FLAC stream from a server to an application is VBR, that certain transients are not handled correctly, like the ringing of bells. If this were true, FLAC would not be lossless in this application. your information is wrong. FLAC does not do psycho-acoustic compression. it does not create artifacts. it is a *lossless* compression scheme. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
2011/5/23 Scott C. Brown 02 scott.c.brown...@alum.dartmouth.org: --- Dennis Brunnenmeyer denn...@chronometrics.com wrote: I've been told that FLAC files, when played back into a high-quality sound system, fail to properly reproduce certain kinds of sounds, like ringing bells or the 'clang' of a triangle. --- end of quote --- maybe he's been reading threads like this: http://www.audiocircle.com/index.php?topic=92852.20 i guess we need to teach people about the cmp(1) and diff(1) commands. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] pkg-config output and FLAC/assert.h
On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo
mle...@mega-nerd.com wrote:
Hi,
FLAC helpfully provides a flac.pc file. Unfortunately there is a
nasty interaction between that file and system header files.
If ones installs flac and relies on pkg-config to find the CFLAGS
one woulf get CFLAGS value of -I${includedir}/FLAC which suggests
that FLAC header files like metadata.h should be included as:
#include metadata.h
However, FLAC also ships an assert.h header file. If one writes
code that wants needs both the Standard C assert.h and the FLAC
header files, we run into a problem, the C compiler finds FLAC's
assert.h instead of the Standard C version.
I believe the correct solution to this problem is the change the
Cflag value in flac.pc to -I${includedir} and then encourage
people to use:
#include FLAC/metadata.h
#include FLAC/assert.h
#include assert.h
which will no longer conflict.
Opinions?
i recall raising this as an issue about 18 months ago. i certainly
feel that the include style that flac uses now is simply wrong, and
that your suggestion above (which matches the one i made) is
substantially preferable.
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] pkg-config output and FLAC/assert.h
On Fri, Mar 25, 2011 at 5:36 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: I'm subscribed to this list. No need to CC me. blame gmail's Reply-To-All ... i don't edit the To: lists it generates ... ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby bri...@sounds.wa.com wrote: All professional tools use conversion factors such as 0x8000 for float-to-int and int-to-float because it has a single significant bit, and thus this factor does not increase the bit depth of the samples passing through. i'm not sure what all means, but i don't think its remotely as clear cut as you insist: http://blog.bjornroche.com/2009/12/int-float-int-its-jungle-out-there.html moreover, its critically important to note that this issue arises primarily for float=16 bit int conversions, where generally dithering should be done anyway. the noise introduced by dithering will be at least on the same order of magnitude as the 0.005% error caused by different choices in the conversion factor. conversions to other bit depths don't face (precisely) the same issue. its great that you're absolutely convinced that your view of this is right. i generally have a lot of respect for your opinions. the problem is that there are 4 other people whose opinions i respect equally, and when i've discussed it with them, my only conclusion in aggregate has to be it depends. --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 3:56 PM, David Richards raw...@gmail.com wrote: Its really sad to hear thats happening but even more sad is the fact that flac is becoming a very common format for music on the interweb whilst at the same time the development has ceased. I've found some severe issues with OggFLAC that essentially make it a useless format for streaming, no one cared. could have fooled slimdevices/logitech, which sends FLAC to all their boxes. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Indexed FLAC file?
On Fri, Jan 7, 2011 at 6:11 PM, Brian Waters brianmwat...@gmail.com wrote: .m3u and .pls playlist files are pretty common and most major media players support them, maybe even embedded ones like the one in your car. David's right, the best thing is to make a database of your stuff (iTunes was good, the last time I had a mac), but then that won't work in your car or anything. For a long time I've wanted to make a web-based music database that does the tables the right way, with foreign keys and lookup tables for artists and albums, instead of the naieve giant excel spreadsheet approach that everything else takes these days. For thirty bucks a month you could stream your stuff to your smartphone and rock out wherever there's a headphone jack. Actually, there is something like that out now (but I thought of it first!), it's called subsonic, and I haven't looked at it. If I ever stop being lazy and build my project, I'll send you an email. a squeeze client for your phone and squeezeserver (now slimserver) on the machine with all the music will do this already. not sure who/want has done a squeeze/slim implementation for iOS or android, but it can't be hard - the source code for a client is all out there. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby bri...@sounds.wa.com wrote: I'd like to borrow these ideas, or at least similarly-inspired ideas, and have FLAC streaming designed such that the stream can tell the playback software when to reset. the internals of the slim protocol does this. its all open source. i was doing some work on this in 2009 to get it to handle multiple sample rates, which it wasn't really designed for, but the reset concept is all there. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compiling static libFLAC.a still requires libogg.dylib
On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord glenn.mcc...@gmail.com wrote: libtool: link: gcc -I/Users/glennm/libOGG-i386/include -O3 -funroll-loops -finline-functions -Wall -W -Winline -arch i386 -arch i386 -o flac analyze.o decode.o encode.o foreign_metadata.o main.o local_string_utils.o utils.o vorbiscomment.o ../../src/share/grabbag/.libs/libgrabbag.a ../../src/share/getopt/libgetopt.a ../../src/share/replaygain_analysis/.libs/libreplaygain_analysis.a ../../src/share/replaygain_synthesis/.libs/libreplaygain_synthesis.a ../../src/share/utf8/.libs/libutf8.a ../../src/libFLAC/.libs/libFLAC.a -L/Users/glennm/libOGG-i386/lib /Users/glennm/libOGG-i386/lib/libogg.dylib -liconv -lm i686-apple-darwin10-gcc-4.2.1: /Users/glennm/libOGG-i386/lib/libogg.dylib: No such file or directory when you tell the linker to use foobar.dylib, it won't go to looking for anything else. if its not there, its an error. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] floating point
On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalsonxf...@yahoo.com wrote: it's unlikely flac will ever support floating-point samples natively. the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else. thats not why floating point is used. the highest current feasible bit resolution for digital audio samples is 24 bits. most converters don't even fully provide that. 32 bit floating bit allows bit-for-bit storage of all 24 bits of the original sample as the mantissa, along with more bits available in the exponent. this provides astronomical headroom for use when summing multiple samples. if you only use 24 bits and add two values very close to the maximum 24 bit value, you will overflow. even if you use 32 bits, its not imposible to construct workflow scenarios where you would overflow. if you do this in float format, you lose a little precision in the answer, but you cannot overflow. this is why floating point is used. flac is designed as a consumer audio format. it trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression. flac seems more popular at present among high end audiophiles than mere consumers. its very regrettable that it doesn't support floating point natively. many of our users (http://ardour.org/) have asked about using FLAC as an option for recording format, but we have to explain that its not viable because of the lack of floating point support. and yes, that is audio engineering :) --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
On Sun, 2008-10-12 at 19:26 -0700, Brian Willoughby wrote: Hello all, Is anyone here potentially up to the task of adding support for CAF (the CoreAudio Format) into the flac command-line? This would present minimal difficulty under OSX, due to the presence of the CoreAudio API, but the real challenge would be to support CAF on Unix and Windows - everywhere that flac is now available. Although the format is rather unknown, there are some very specific advantages to adding CAF support. I am a little suprised that you don't know that CAF is already supported by libsndfile, on every platform where libsndfile works (which includes just about every unix and windows platforms i know of). ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] 1.2.1 pkg-config file error
hi, and sorry that my first post to the list is a complaint. the .pc file for 1.2.1 produces this for --cflags: -I$PREFIX/include/FLAC i humbly suggest that this is wrong. it appears to support inclusion of FLAC headers with #include filename.h rather than #include FLAC/filename.h but more importantly, it means that when building an app using pkg-config to determine compiler flags, we end up with a rather serious problem as soon as the app uses assert.h: #include assert.h combined with: -I/usr/local/include/FLAC means that we find the FLAC assert.h file first. this file the tries to help out by doing #include assert.h which simply causes it to include itself again. The .pc.in file should use $PREFIX/include for the cflags, not $includedir which is where the headers are installed. apps should use FLAC/foobar.h to include FLAC headers, not foobar.h as this mistake with assert.h demonstrates. --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
