similar to: Mac OS X flac - domain name change

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

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,

Hi folks, I would announce this on [Flac] instead of [Flac-dev], but it hasn't been widely tested yet. With that caveat, if you don't want to download the flac 1.1.4 sources and build them yourself, check out http://www.sounds.wa.com/ software/flac-1.1.4.dmg The installer includes the Ogg 1.1.3 library as well as flac 1.1.4, but you can turn either package installer off in the

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

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

hi, according to the FAQ flac supports multichannel formats. i had no luck with 1.1.4 though ( "Untitled.aif: ERROR: unsupported number channels 8 for AIFF" ), i guess that feature was added in 1.2? unfortunately, the binary for 1.2 does not run on OS X 10.4 (says libiconv is too old). i removed libiconv and reinstalled that from source, but then flac 1.2.1 just prints

Thanks folks, I have an Intel build already! On Nov 15, 2007, at 03:58, Rippit the Ogg Frog wrote: I can do it, but possibly not till Friday evening. I'll do it today if I do get some free time. Mike Crawford aka Rippit the Ogg Frog Brian Willoughby wrote: > I'm putting together a Universal Installer for Mac OS X, but I > currently do not have access to an Intel Mac for that

The problem is really as I wrote: 1. Metaflac is no option for me, I use libFLAC.dll 2. There is no way (at least how I read the code) to avoid saving comment with libFLAC; I would appreciate an extra option to avoid it, which can default to old behavior if compatibility is important. 3. I have a high speed application, where re-initializing an encoder is really significant. On corner cases it

I wasn’t suggesting that you run metaflac, but that you examine its source to see how it creates new FLAC files without the Vorbis comment. As far as I know, metaflac uses the standard libFLAC and creates files without the Vorbis overhead. My quick review of the source seemed to indicate that calling FLAC__metadata_object_new(FLAC__METADATA_TYPE_VORBIS_COMMENT) will create the comment, but I

Security is quite important, but I believe that audio quality and lossless performance trump security for nearly all users of flac. In other words, unless the bugs affect the lossless quality of flac, then those old downloads should remain available. Of course, place a notice about the potential for security issues, but let the users make their own decisions. Personally, I find it important to

Hi folks, I'm putting together a Universal Installer for Mac OS X, but I currently do not have access to an Intel Mac for that half of the build. Cross-compiling does not seem to work, at least not easily. I am hoping that one of you could build flac 1.2.1 with ogg support, and then - after 'make install' - use gnutar to package up everything that is added to /usr/local/

---------------------------------------- > From: brianw at sounds.wa.com > Date: Wed, 25 Mar 2009 19:10:34 -0700 > To: flac at xiph.org > Subject: Re: [Flac] Build FLAC source on Mac OS X without Xcode? > > Ok, what follows is a successful build of FLAC on Tiger 10.4.11 from > the downloaded source "the Unix way": > > mkdir test > cd test > gnutar zxf

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

that's why i asked the original poster if the files were odd size, i had that issue before with a 24 bit mono file and wrote this script to fix it: #!/bin/sh # # sfoddfix - Sound File ODD size FIXer # # NOTE: flac v1.1.2 pukes on files that have an odd byte count, this pads them files=${*:-*.wav} for file in $files do size=$(stat --printf='%s' $file) if [ $(($size%2)) -ne 0 ];

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

---------------------------------------- > CC: flac at xiph.org > From: brianw at sounds.wa.com > Subject: Re: [Flac] Build FLAC source on Mac OS X without Xcode? > Date: Sun, 22 Mar 2009 14:33:36 -0700 > To: jensiragh at hotmail.de > > I don't have time to look through error codes, but I can tell you > that I have always compiled FLAC the Unix way, via the command

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

I have exactly the same problem. I encoded a BWF file to flac and then then decoded back to wav, using --keep-foreign-metadata, and I ended up with a bit-perfect copy of the original BWF. So I was fairly confident that the flac encoding is working correctly, the problem definitely appears to be with the flac players. Unfortunately it seems that the majority of flac players cannot play 24bit