similar to: flac alpha with RIFF/AIFF metadata support

The patch I submitted only reads AIFF files. I'm about to start the patch to write AIFF files. To do so, we need a command-line option to specify AIFF. My inclination is to add an option: -ff { raw | wav | aif } In some sense, "-ff" is silly since it probably stands for "format format". Still, I think it's better than just "-f", since the first

I know this is probably blindingly obvious, but I can't find it anywhere. Is there a way to tell the Vorbis codec what endian your samples are or do I have to do my own byte reversal. AIFF is Be's 'standard' audio file format, and its encoded big endian, not little endian even on Intel boxes. I know for decoding ov_read has an endian option, but I can't see an equaivalent for

flac.exe is choking on some aiff files as input with the following: "ERROR: SSND chunk size inconsistent with sample frame count" According to Daren on the dBpoweramp forum "The flac.exe program ignores the amount of data bytes quoted in the SSND chunk and tries to read to the end of the file, which would be fine if the SSND data was the last data in the file. The problem is

Hi all, I was reading the discussion about this 1.3.0pre1 release on HydrogenAudio and someone linked an old thread in which one patched FLAC 1.2.1 to support WAV-files larger then 2GB. It might be worth investigating: http://www.hydrogenaudio.org/forums/?showtopic=84014#entry725304

Not sure if this belongs here or in flac-dev. I am subscribed to both, so flop it over if fits better over there. Looking at the Changelog for FLAC 1.2.1 (17-Sep-2007), it says: "With the new --keep-foreign-metadata in flac, non-audio RIFF and AIFF chunks can be stored in FLAC files and recreated when decoding." Where can I find more detail on what is a

--- Matt Zimmerman <mdz@debian.org> wrote: > On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote: > > > The patch I submitted only reads AIFF files. I'm about to start > the patch to > > write AIFF files. > > > > To do so, we need a command-line option to specify AIFF. My > inclination is to > > add an option: > > > >

Hullo, PP5020-based iPods can now play Vorbis in real-time, with iPodLinux! http://www.ipodlinux.org/blog/index.php?p=18 I got this from Hydrogenaudio. http://www.hydrogenaudio.org/forums/index.php?showtopic=34602 Cheers, Kyungjoon Lee

There are several links to Windows compiles in the Hydrogenaudio thread for FLAC 1.3.0 at http://www.hydrogenaudio.org/forums/index.php?showtopic=101082 . On Unices or Linuxes building from git should be straightforward enough, or you wait until the distributions/package maintainers catch up. Also, congratulations to the whole development team for reinvigorating FLAC! Christoph On

--- august <august@alien.mur.at> wrote: > > > sorry to bother again, > > but I can narrow down my problem to certain parst of my flac file. > > for example, when I seek to 19*44100 samples or to 81*44100 samples, > the > seek callback runs off in an endless loop. > > there aren't any while loops in my code, so I don't think I am > causing it.

There is a thread over on Hydrogen Audio forums: http://www.hydrogenaudio.org/forums/index.php?showtopic=99757 I will answer what I can here. > mudlord says : > As usual, Fidel Castro Loco ignored Windows. Wrong. As the git logs show, I have commited a bunch of windows specific fixes myself as well as commiting windows fixes by others. > zfox > My own Linux build could not

I have a test program that loads an AIFF or WAV file with libsndfile and plays then using libao. After running around in circles for a while, I found and fixed the problem, but I'm still confused as to why the solution works. Would someone please explain this to me so I don't trip over this again later in my project? I used sf_open_fd() to get a SNDFILE* pointer and an AF_INFO

Hello Earl, I used your patches while they cleanly applied to the Git tree. There is one question though, what do you think of?. http://www.hydrogenaudio.org/forums/index.php?showtopic=84086&st=0&p=782407&#entry782407 which apparently states (if I understand correctly) that your approach is not completely correct. Kind regards, Michael -------------- next part -------------- An

Hi, > If I understand this correctly, these new apodization functions only > affect compression and that files compressed with these new functions > will still decode correctly with older versions of the FLAC decoder. > > Is that right? Yes, that is correct. These functions are used to window the audiodata, but only for the predictor stage. What these new function enable,

So, in a thread on HA a user asked if some logo was the official one for Vorbis. It turned out not to be, but everyone agreed the official logo was ugly and a bad idea to add on any portable player compilant with Vorbis (or other Ogg media for that matter). The chaps, me included, started a discussion of a redesign, but truth be told, if Xiph isn't interested in a redesign, there's no

On 04-03-13 23:19, Erik de Castro Lopo wrote: > Link please? http://www.hydrogenaudio.org/forums/index.php?showtopic=99757 > Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig.

On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote: > The patch I submitted only reads AIFF files. I'm about to start the patch to > write AIFF files. > > To do so, we need a command-line option to specify AIFF. My inclination is to > add an option: > > -ff { raw | wav | aif } > > In some sense, "-ff" is silly since it probably stands

How about the opposite? What I would like to see is FLAC support in libaudiofile, so applications written with libaudiofile could transparently take advantage on FLAC's compression. Ironically I guess it would still make sense to use libaudiofile in FLAC for getting input. Mmmm, cyclic dependancies... Or is that just a stupid idea? Dave On Wed, 2002-07-31 at 13:10, Matt Zimmerman wrote: >

Hi everyone, Recently I made an attempt at merging the tunings of GT3b1 into the official Xiph.org 1.0.1 libvorbis code. While 99% of the GT3b1 tunings are independent of 1.0.1, there is one particular value (_psy_noiseguards) which affects the whole quality range. I've chosen to use the 1.0.1 values since they changed since 1.0. Therefore, files encoded in GT3b1 mode (q 5 and above)

Vorbis, using the AoTuV beta4.51 encoder, come first in a "Public, Multiformat Listening Test @ 128 kbps" organized on Hydrogenaudio forum. Hydrogenaudio thread: http://www.hydrogenaudio.org/forums/index.php?showtopic=40607 Presentation: http://www.maresweb.de/listening-tests/mf-128-1/ Results: http://www.maresweb.de/listening-tests/mf-128-1/results.htm

Hi, We have already pointed out multiple times in the HydrogenAudio thread ( http://www.hydrogenaudio.org/forums/index.php?showtopic=99653 ) why we think this is a bad idea. These include (off the top of my head): 1) The Opus decoder does not have a bit-exact definition 2) It would require a bit-exact resampler too (the one from opus-tools isn't bit-exact even in fixed-point) 3) Opus has