similar to: Universal Binary Installer for Mac (pre-release)

yes that is what i did. got the "requires version 7.0.0 or later, but libiconv.2.dylib provides version XYZ" (forgot which version i had before). removed libiconv, downloaded compiled and installed the new one (libiconv-1.13.1), then i just get $ flac Bus error i reinstalled flac 1.1.4, still runs fine (but doesn't support multichannel). cheers, -sciss- Am 05.08.2009 um

I am hosting Mac OS X builds of flac 1.1.4 and 1.2.1, but my domain name changed earlier this year. So, those old links on flac.sourceforge.net for sounds.wa.com are now audiobanshee.com, e.g. http://www.audiobanshee.com/software/flac-1.1.4.dmg http://www.audiobanshee.com/software/flac-1.2.1.dmg I couldn't access SourceForge.net earlier today, maybe their site was down. My site is up,

Brian Willoughby <brianw at sounds.wa.com> > Isn't there a standard option to place FLAC data within an Ogg > container? I don't use it myself, but I understand that it is quite > popular. Would it be possible to interleave multiple FLAC blocks > this way? In other words, can Ogg suffice as the second level of > grouping that you refer to? Etienne was asking for

On 2/21/07, Brian Willoughby <brianw@sounds.wa.com> wrote: > > The key to Arek comment is that the project files only work with 1.1.2 FLAC. > Even in those days, the Xcode project was not fully operational. I gave up > on using it, and I think everyone else did. You basically have no hope of > just pulling it out of the repository and expecting it to work. Brian, you

I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to

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

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

--- Brian Willoughby <brianw@sounds.wa.com> wrote: > Hello, > > I noticed that there is no convenient installer package for Mac OS X. > The > various GUI programs that use FLAC seem to only have flac 1.1.0, so > there is no > simple way for a non-developer to install flac 1.1.1, other than > manually > placing the various files where they belong. > >

Harry, Keep in mind that the processor load will be different for every processor model. PowerPC G4, G5, and then all the implementations of x86. Processor load does not depend upon clock speed - all that clock speed determines is how fast the operation can be done, and particularly whether it can be done in real time. Back to your question: The CPU load will be determined by the

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

Version 1.2.1 of the standard/spec or the local implementation? I've not seen "FLAC 1.0/1.1 Compliant" or "FLAC 1.2 Compliant" on the specs of hardware gear for example when FLAC is stated supported. Just a curious on-looker. On 7 February 2011 02:34, Pierre-Yves Thoulon <py.thoulon at gmail.com> wrote: > Version 1.2.1 introduced new rice coding techniques

Version 1.2.1 introduced new rice coding techniques that are used by the reference encoder for 24 bit files. An older version of the decoder will have trouble with frames that use this encoding... Maybe that's where the strange noises come from... Pyt. On 6 f?vr. 2011, at 06:01, Brian Willoughby <brianw at sounds.wa.com> wrote: > Thanks for bringing up this aspect, Nicholas. I

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

--- Brian Willoughby <brianw at sounds.wa.com> wrote: There are no uncompressed files here, so it's difficult to discover what you need to know. --- end of quote --- I've asked him for the uncompressed first track to see what the correct md5 should be --- Brian Willoughby <brianw at sounds.wa.com> wrote: This could be an uploading problem. There are still too many

No, streams should stay. Audio is NOT a file based process -- it's a stream. You can't listen to an entire song simultaneously. You organize it into files for later use, but you listen and record from a stream. Stream-based storage is practically REQUIRED for an audio codec. It's not random access, it's sequential. You can put wrappers around it to make it convenient for file

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

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,

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

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

Ok, I just did a comparison of 1.2.1 with 1.3.2, and the change you're suggesting was already there before. So, now the question becomes: why was the code changed in the first place? Was there a bug that was fixed by changing 17 to 16, or did someone just get overzealous in a code review and thought that 17 was a bad choice? Perhaps 32 bits isn't actually large enough to handle the