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 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
2011/5/23 Scott C. Brown 02 : > --- Dennis Brunnenmeyer 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] Variable Bit Rate
On Mon, May 23, 2011 at 2:35 PM, Dennis Brunnenmeyer 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] pkg-config output and
On Fri, Mar 25, 2011 at 5:36 PM, Erik de Castro Lopo 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] pkg-config output and
On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo
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 should be included as:
>
> #include
>
> However, FLAC also ships an header file. If one writes
> code that wants needs both the Standard C and the FLAC
> header files, we run into a problem, the C compiler finds FLAC's
> 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
> #include
> #include
>
> 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] Support for CAF in flac command-line?
On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby 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 Sat, Jan 8, 2011 at 8:39 PM, grarpamp wrote: > Yes, this is sad. cdparanoia, which could be considered a strong > opensource meatspace partner to FLAC (along with cdda2wav) > is also effectively dead. All three living on only in the ports trees of > various operating systems. Minor bugs and doc fixes are always > needed. What's worse is, when the heat turns up on dead projects, > instead of just stepping up or handing off in a competitive/proposal/worthy > yet time limited process, the authors emit some sort of lame 'Hey yeah, > new release coming' message in an attempt to maintain ownership, which > of course goes nowhere. It's really just a disservice to themselves and the > community. Sad indeed. Have people forgotten what opensource is all about? > There are plenty of people capable of doing these two. Certainly ripping. > Fork I > say. I love these projects, and their authors. So not as an affront to prior > authors, but for betterment of the projects, always. did you read brian w's explanation of why FLAC appears "dead" ? the same thing really applies to cdparanoia, a program now more than 10 years old, maybe even 15. some things about ripping audio CDs just don't change. ___ 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 8:29 PM, Brian Willoughby wrote: > Awesome! Can ya help a brotha' out and send some links to the slim > protocol? I suppose Google could find it for me, but if you're familiar > with the project then I'd appreciate an insider's pointers. alas, i got my copy of the source from a 3rd party that had already hacked it quite a bit to support a fairly high end playback device. my guess is that logitech's download/support section of their website would have it. but if you decide to look at it, stay away from the perl and stick with the C. > A friend has some old slim hardware, and I've been trying to help him with > converting files for playback, so I do have a little bit of experience with > the history. i'm not convinced that its necessarily the same kind of reset, since slim is not a broadcast server - each client has its own independent stream. but ... there is a way to sync multiple players, and that must involve some similar magic. --p ___ 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 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] Indexed FLAC file?
On Fri, Jan 7, 2011 at 6:11 PM, Brian Waters 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] Idea to possibly improve flac?
On Fri, Jan 7, 2011 at 3:56 PM, David Richards 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] Compiling static libFLAC.a still requires libogg.dylib
On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord 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 6:47 PM, Brian Willoughby wrote: > When the ADC source and the DAC destination are both limited to 24- > bit fixed point integers, it makes absolutely no sense to store > recordings or final mixes in 32-bit floating point representation. > The headroom you speak of is completely unavailable when storing the > output of an ADC into a file. Likewise, headroom is wasted when > playing back a fully mastered piece of audio to a 24-bit DAC. > Headroom is only an issue when you want to work on the audio and > change it, which is something that 99% of audio consumers do not > bother with or even understand. You're assuming that you never store intermediate mixes that may actually have overflowed a 24 or 32 bit representation. I would agree that this might not be best practice, but its actually not as un-useful as it might at first appear. > inappropriate. It would be quite interesting if someone were to > create a lossless format which can handle 32-bit float, but I don't > believe it has been done yet. wavepak (pack?) does. In most respects, this would mostly be > a tradeoff between storage space and processing power, since > processing a compressed file is usually too expensive for most DAW > software, and so they always uncompress source files before using > their data. Thus, even a space-saving format like FLAC would be > pointless for Ardour, since you'd still need to take up disk space > for an uncompressed copy of the data (like Ableton Live, which > supports FLAC). its always a tradeoff between CPU cycles and disk space. you don't need an uncompressed copy if you're prepared to burn the CPU cycles. i'm not an advocate for Ardour using FLAC as a native format. i just don't like telling users "it can't be done". ___ 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 Coalson 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 rather than #include 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 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 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 to include FLAC headers, not as this mistake with assert.h demonstrates. --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
