Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
On Jan 2, 2007, at 1:54 PM, Josh Coalson wrote: this is reported a lot. usually it is a misunderstanding in how to send samples to FLAC__stream_encoder_process() or FLAC__stream_encoder_process_interleaved(). if you could send your code where you are doing that, it would help. note that samples going in to the process calls must be converted to signed 32-bit integers (this is lossless) regardless of the initial format. see also: http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga63 from your description it sounds like you might be sending packed 16-bit samples somehow which could cause every other sample to get encoded. OK, now I'm totally stumped. I can confirm that I'm sending the encoder 32-bit signed integers, and that they are correctly representing the original file. I still get a silent file. I tried making the resulting integers forcibly little-endian, and I got a FLAC file result that sounded like what a byte-reversal might sound like - noisy when there's data, but 0 is 0. I've heard it before, I recognize it... But why when I send it *correctly* to the encoder do I get silence? Another clue is that they see to be super-small files, but with the proper length. Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
--- Evan Olcott [EMAIL PROTECTED] wrote: On Jan 2, 2007, at 1:54 PM, Josh Coalson wrote: this is reported a lot. usually it is a misunderstanding in how to send samples to FLAC__stream_encoder_process() or FLAC__stream_encoder_process_interleaved(). if you could send your code where you are doing that, it would help. note that samples going in to the process calls must be converted to signed 32-bit integers (this is lossless) regardless of the initial format. see also: http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga63 from your description it sounds like you might be sending packed 16-bit samples somehow which could cause every other sample to get encoded. OK, now I'm totally stumped. I can confirm that I'm sending the encoder 32-bit signed integers, and that they are correctly representing the original file. I still get a silent file. I tried making the resulting integers forcibly little-endian, and I got a FLAC file result that sounded like what a byte-reversal might sound like - noisy when there's data, but 0 is 0. I've heard it before, I recognize it... But why when I send it *correctly* to the encoder do I get silence? Another clue is that they see to be super-small files, but with the proper length. it's probably getting buffers of zeroes (or a constant number); that compresses really well with FLAC. at this point I think I'll need to see your code up to and including your call to FLAC__stream_encoder_process() where it fills the buffer in order to be able to figure it out. Josh __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
--- Evan Olcott [EMAIL PROTECTED] wrote: On Jan 3, 2007, at 3:28 PM, Josh Coalson wrote: the FLAC parts look OK but I don't know how the audio converter works. I think that's where the problem is. it is probably converting float to 32-bit int full scale. well, here's what I found out about the 32-bit integer conversion. If the original 16-bit sample is 0x52F3, it goes through floating point, then comes to the 32-bit integer as 0x52F3 As far as I know that's the proper conversion, yes? Simple adding some LSB to make it 32-bit. but if [audioFile range] is 16 (i.e. 16 bits per sample), then after conversion, the integer PCM samples in outputBuffers should all be in the range [-32768,32767], that's the first thing I'd check. OH so wait... What you're saying then is that the buffers always have to be filled with 32-bit-SIZED-FIELDS, inside of which exists a low-aligned integer sample value? So the VALUES aren't 32-bit integer, but the SPACE FOR THE SAMPLE VALUE is 32-bit. Wow, that's very trippy. Honestly, I *never* would have guessed that from the documentation. That would explain the silence, too. yep, that's right. I'm adding this sentence to the docs which should hopefully clear things up in the future: Each sample should be a signed integer, right-justified to the resolution set by FLAC__stream_encoder_set_bits_per_sample(). For example, if the resolution is 16 bits per sample, the samples should all be in the range [-32768,32767]. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
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/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
--- Evan Olcott [EMAIL PROTECTED] wrote: 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? this is reported a lot. usually it is a misunderstanding in how to send samples to FLAC__stream_encoder_process() or FLAC__stream_encoder_process_interleaved(). if you could send your code where you are doing that, it would help. note that samples going in to the process calls must be converted to signed 32-bit integers (this is lossless) regardless of the initial format. see also: http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga63 from your description it sounds like you might be sending packed 16-bit samples somehow which could cause every other sample to get encoded. Josh __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
--- Evan Olcott [EMAIL PROTECTED] wrote: 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... the file and seekable stream layers have been merged back into the stream layer for both encoder and decoder, to make the API simpler. so those files you mentioned no longer exist. see also: http://flac.sourceforge.net/changelog.html http://flac.sourceforge.net/api/group__porting.html Josh __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
--- Evan Olcott [EMAIL PROTECTED] 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC fully cooked for OS X yet?
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/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
