similar to: Is FLAC hardware independent?

Which "output file" are you referring to? Also, your question is incompletely specified, because you do not qualify whether the input is the same when you expect the output to be the same. When uncompressing, the final results are lossless, therefore it is hardware independent when you consider the total process. When compressing, the results depend upon the implementation. In

Dear list, We are investigating about some state-of-the-art lossless audio codecs and their performance in terms of? rate and compression ratio. Therefore, it is very important to us to know whether a codec is hardware independent, i.e. if it produces the same output file regardless of the hardware. Could you please tell me whether FLAC is hardware independent? Thank you very much in advance.

Hello Rene, If you want to be sure that you get no information loss, I suggest a very simple test. Recover your WAV file from any of the FLAC files you mentioned in your e-mail. If this WAV file is bit-by-bit identical to the input WAV file, then you have no information loss. Also, it is important to take into account that the compression ratio is highly dependent on the encoded wav file. If you

On Nov 12, 2009, at 16:32, Fernando Alberto Marengo Rodriguez wrote: > I' m studying FLAC performance, and I'd like to know how much > compression can be achieved for different audio files. > > 1) It seems that for nontonal sound (wideband noise), the > compression factor is better than for compound sound (tones + > nontonal components), which is typically 2. The

On Jul 18, 2015, at 10:46 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > Op 16-07-15 om 07:50 schreef Brian Willoughby: >> On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie> wrote: >>> Can anyone on the list (possibly someone who works for MSFT) get this >>> fixed before Win10 is released? >> What size differences are we talking

Dear list, > Which "output file" are you referring to?? Also, your question is incompletely specified, because you do not qualify whether the input is the same when you expect the output to be the same. My question is the following: For any encoding option (e.g. -5, default), does the flac encoder produce the same byte-for-byte output regardless of the CPU? Regards, Fernando

Dear list, I' m studying FLAC performance, and I'd like to know how much compression can be achieved for different audio files. 1) It seems that for nontonal sound (wideband noise), the compression factor is better than for compound sound (tones + nontonal components), which is typically 2. The reason for this result could be the following: the LPC filter is more suitable for

Came across another error that might help! Using flac -t I get: 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC Thanks, Matthew On Feb 6, 2008 3:19 AM, Matthew Davis <zasdarq@gmail.com> wrote: > Thank you for the reply! I know that my system can play flac files, I've >

> PS: Here is the answer of David Bryant, the developer of WavPack: "The WavPack codec is hardware independent; the standard "C" encoder will produce the same byte-for-byte output regardless of the CPU it is running on (assuming a properly working C compiler, of course)." The same is true of flac, as long as you're using the same version of the encoder, right? The same

On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby <brianw at sounds.wa.com> wrote: > Frederick, > > This is great news! Thanks for your effort. > > Your proof-of-concept raises a few questions for me: > > 1) I know that the ratio of uncompressed to compressed data is > unpredictable, but I never really considered whether the input block size or > the output

On Jan 7, 2011, at 17:18, Paul Davis wrote: > On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby > <brianw at 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

Hi Neil, I think you have a misunderstanding or two. What you want to do does not require "code." In fact, you might want to move your question from the FLAC-Dev list to the FLAC (User) list. I'm on both lists, so I did not realize that you were basically asking in the wrong place. No "coding" skills whatsoever are required to create seekpoint markers in a

Hi Justin, Are you saying that 24-bit support does not work for you? Which version of FLAC are you using? What platform? What kind of files are you trying to compress? I am not any kind of official spokesperson for FLAC, but this alleged report about 24-bit problems surfaced in Aug 2006. However, I have been successfully using 24-bit FLAC since June of 2004, and I have never seen a

And more info... Screen capture of the WAV file's hex. This tells me little, but maybe someone out there knows more about this than me. http://img139.imageshack.us/my.php?image=screenshot251awavghexnd1.png Thanks again, Matthew On Feb 6, 2008 12:18 PM, Matthew Davis <zasdarq@gmail.com> wrote: > Came across another error that might help! Using flac -t I get: > > 251_A.wav:

Harry Sack wrote: > > > 2007/3/29, Brian Willoughby <brianw@sounds.wa.com > <mailto:brianw@sounds.wa.com>>: > > There actually is no problem with 24-bit support, as I stated > earlier. So before people start chiming in with "me too" - I'd > like to request that you actually say what problem you're seeing, > along with a few

Thank you for the reply! I know that my system can play flac files, I've played others I've managed to convert using both of those programs. I'm only running into difficulty when it comes to these large WAV files. By "Does not work" I mean that they do not play, and instead I receive the errors I mentioned in my original post. I wasn't actually intending to use

You could also try SoX. It looks like that program could convert directly from FLAC to MP3, but I haven't tried it. I have a Sound Devices recorder that supports FLAC, but it doesn't play all files from external sources. It's great for recording to FLAC, but not so good for playing files purchased online in FLAC format. Brian Willoughby Sound Consulting On Jun 5, 2016, at 5:28 PM,

This could make sense indeed. I suppose this is not a libFlac feature and that I should end up using libogg and or adding myself basic ogg support in order to support that ? Thanks ! 2017-01-28 7:37 GMT+01:00 Brian Willoughby <brianw at audiobanshee.com>: > Don't overlook the FLAC in Ogg container solution. That's established as a > standard for some time now, as far as I

Oops. I proofread my email a little too late. I corrected the example. Hopefully what I am suggesting is clear. Brian Willoughby Sound Consulting On Jun 22, 2010, at 22:15, Brian Willoughby wrote: > What you need to do is write a bitStream function. It should only > read each byte from the stream once and completely deal with all 8 > bits before reading the next byte. You

On Mar 6, 2011, at 01:22, Erik de Castro Lopo wrote: > Brian Willoughby wrote: >> Hopefully, libsndfile no longer uses the incorrect 0x7FFF (32767) >> factor for float to 16-bit integer conversions, because that would >> make it unacceptable for lossless file conversions. > > That is a statement of opinion rather than fact but I won't go into > that here. It is