OK, so I've been trying for a day now to get FLAC implementation in our apps. Suffice it to say that due to the "interesting" documentation and the inability to compile this thing from the source, I'm not sure we can do it yet. I am writing in to see if there's anything I'm missing before I make the conclusion that we have to wait... --- We write apps for OS X, and we're fully Universal, so we need to really make these OS X frameworks. I nudged around and I found a pre- built FLAC.framework inside some Xiph installer somewhere, so I based some of my work on that. There are a few files called seekable_stream_encoder and file_encoder that have headers and seem to be ready to use, but it seems like their buffer usage is incorrect in my experiments. I go further to find that - hey - there's no real documentation for these files, and they don't even exist in the repository! Are they beta? Are they not fully formed? Why are they here if they don't work? Knowing that wasn't working, I downloaded the XCode project from a link on the mailing list, only to find that these "uncooked" files *exist in the XCode project*, but cannot be actually found anywhere! So I take the files out and try to compile the XCode project as it is - and it gives all sorts of link errors trying to find FLAC__window_... calls, which cannot seem to be found in ANY of the files in the repository... What the heck is going on here? Do we have to wait for a bit to get this thing settled? Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070101/1220ee72/attachment.htm
Hi, The XCode project files you found are meant to be used with FLAC 1.1.2. The FLAC repository now contains version 1.1.3 files, and there have been interface changes in that latest revision (http://flac.sourceforge.net/changelog.html#flac_1_1_3). That could explain your problems with compilation. The binary frameworks distribution, as found on: http://xiph.org/quicktime/download.html , hasn't really been tested much outside the XiphQT project. I never had any problems with them, but any improvement suggestions or help is welcome. Arek
On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote:> The binary frameworks distribution, as found on: > http://xiph.org/quicktime/download.html , hasn't really been tested > much outside the XiphQT project. I never had any problems with them, > but any improvement suggestions or help is welcome.Well, ok, then if the framework is intended to work, then let me describe closer the situation I'm seeing: I'm using FLAC__file_encoder_process to encode the audio I'm getting into an FLAC file. I can prove that the audio I'm sending it via the buffers is valid: I've written it to a raw file to confirm it's the same as the source file, and it is. I've tried it with multiple channels and single channels to the same error. I'm giving the processor audio in blocks of 1024... The file apparently gets created successfully, but when I convert the FLAC file back to aiff (using MacFLAC - I haven't written a decoder just yet), it seems like the blocks were written to the encoder with the first 512 samples being every *other* sample, and the remaining 512 of the block being random data. This continues throughout the file. I have double and triple checked my buffering techniques and they are indeed giving it the audio data I want to give it, and this just seems like bad buffer usage in the file_encoder side. (Thus my reasoning for wanting to step through it with the source)... Are there any ideas about this, is it a known issue? Is there something I need to be setting up that I'm not? Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/
On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote:> The XCode project files you found are meant to be used with FLAC > 1.1.2. The FLAC repository now contains version 1.1.3 files, and there > have been interface changes in that latest revision > (http://flac.sourceforge.net/changelog.html#flac_1_1_3). That could > explain your problems with compilation.Well, now, no, I did download the 1.1.3 sources again, and not only did the xcodeproj project file have the file_encoder.c listed in the project as WELL as the old pbproj project file that came WITH 1.1.3's sources, i did a search on the whole directory only to find no trace of file_encoder.c and it's cousins... I'm all at 1.1.3, source files, project files and everything. Now, where did these files go?: file_decoder.h + .c file_encoder.h + .c seekable_stream_decoder.h + .c seekable_stream_encoder.h + .c Who's got 'em? They're certainly not in the distribution -- does anyone actually HAVE these files anywhere? Looking for these files on the api repository gets me a 404... but Google has links to them... Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070102/1bb22833/attachment.html
--- Evan Olcott <ev@audiofile-engineering.com> wrote:> OK, so I've been trying for a day now to get FLAC implementation in > our apps. Suffice it to say that due to the "interesting" > documentation [...]could you elaborate? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Jan 2, 2007, at 1:56 PM, Josh Coalson wrote:>> OK, so I've been trying for a day now to get FLAC implementation in >> our apps. Suffice it to say that due to the "interesting" >> documentation [...] > > could you elaborate?Well, I've just never seen anything like it before. There's a step- through, to be sure, but I got more information out of the headers than the actual online stuff, which seemed very intra-linked, very, shall we say - generated automatically... I'm used to Apple's documentation, which is very clean and clear. This seemed a little overkill - lists of functions, lists of headers, lists of classes, alphabetically (even though 99% of them all start with FLAC__), etc. It seemed a little "too much" where it looks like it could be a lot simpler - the API isn't really as complex as it looks like at first glance... Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070102/ad46a061/attachment.htm