similar to: FLAC 1.0.5 beta1 released

Awesome, I'm psyched for 1.0.3.... the ID3v1 winamp2 support will be a neat addition, as is the faster decodes. Will 24-bit audio play nice with the final public version of 1.0.3? MW On Tue, 11 Jun 2002, Josh Coalson wrote: > One more thing... you will probably have to > > chmod +x flac-1.0.3_beta/test/test_streams.sh > > before doing the 'make check'. > >

According to http://flac.sourceforge.net/format.html#metadata_block_streaminfo : "FLAC supports from 4 to 32 bits per sample. Currently the reference encoder and decoders only support up to 24 bits per sample. " This is why I'm confused. I though one of the benefits of FLAC was it's ability to encode in word lengths longer than 16 bits. MW -----Original Message----- From:

Great call, Jason. The trouble may also be from overclocking their CPU's. We ran into some similar bug reports in the Furthur project with people swearing up and down that random application hangs and glitches was our software (which in part it was). However, as soon as they brought their CPU's and video cards back to spec, their problems magically went away. I would follow this one up

Which plugins do you mean? I thought I remember Winamp, for instance, being able to do word-length reduction on the fly. The only place I can find this feature is in the Monkey's Audio codec plugin, though. Anyway, great news Josh! Thanks for making 24-bit audio support in FLAC a priority. :) MW On Tue, 11 Jun 2002, Josh Coalson wrote: > --- Mike Wren <mikew@etree.org>

I'm moving this over to flac-users... Anyway, are you using Mike Wren's installer? I'm not familiar with that yet. Josh --- C&K Slagle <ckslagle@earthlink.net> wrote: > have winamp installed on a partitioned drive. > I installed the most recent version of Flac which includes the plugin > for > winamp. However, .flac files are not recognized in winamp.. Is it

I know this is probably a really stupid question, but why is FLAC's MD5 checksum different than the MD5 checksum of the original (input) .wav? I was under the impression that since each FLAC file contains metadata that can be changed without changing the audio (thus changing the MD5 checksum of that FLAC file) that the checksum of the original .wav file would instead be used. If that's

The Winamp3 hit the streets yesterday, so i gave the FLAC Winamp3 plugin a shot (dragged cnv_flacpcm.wac to the Wacs/ directory, yadda yadda) and received the following error message when starting Winamp3: --- Studio.exe - Entry point Not Found The procedure entry point_chkesp could not be located in the dynamic link library MSVCRTD.dll. -- It's unable to play .flac files, but still plays

This is a fantastic selling point, and one that I've never really thought of. Back in the early days of etree (a whole three years ago ;) ), before we learned the virtues of MD5 sums for SHN downloads, I downloaded a Hornsby show from someone. Of course, an MD5 wasn't available, but when I decompressed and Shoren didn't throw a sanity error my way, I figured all was well. I burned

On my lists of things to do for 1.0 were 1) improve seeking; and 2) speed up both encoding and decoding. Seeking seems better now (I added the SEEKTABLE and tweaked the search algorithm). On the way, one of my encoding experiments worked. By taking advantage of a relatively unused area in the Rice parameter space, I added an escape code for switching to flat encoding within a partition.

I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to

First, thanks to everyone for putting in their time to make the first truly "free" lossless audio codec. I'm co-founder of etree.org, the largest online community of lossless audio traders (currently 12,000 active members). We have been living in the shadow of Shorten for almost three years. Shorten, as most of you have come to realize, is extremely limited in terms of

Sorry to be so slow in responding. I've done what you suggested. I created /etc/sysconfig/desktop and entered "$DISPLAYMANAGER=KDM". I rebooted but there was no change. GDM is still being used. Any other suggestions? mw ======================== Just create the file /etc/sysconfig/desktop and put in it: DESKTOP=KDM I believe it's DESKTOP - you can dbl check /etc/X11/prefdm

Using the FLAC frontend with flac v1.0.2, I tried to encode a recently recorded 24-bit mono wav to flac, but received the following error: options: -P 0 -b 4608 -m -l 12 -e -q 0 -r 0,6 -R 0 gpt2002-06-01mono.wav: ERROR: unsupported bits per sample 24 So, I tried to encode a stereo 24-bit wave file... same error. I'm using the .exe of flac v1.0.2 under Windows 2000. The wave files can be

Josh Coalson wrote: > yeah, flac doesn't have a 'gzip' fallback method > so any non-audio data will probably get stored > verbatim. I'm kind of reluctant to add a generic > compressor. If you wan't, you could come up with a > FLAC metadata block to store a gzip'ed chunk and I > could add that to the format. > I had the same thought when I was

> Any thoughts to perhaps integrating a quick sector-boundary check of the > wav file before encoding? Does this functionality extend beyond the scope > of FLAC? A quick check, and a "this wav file is not cut on a sector > boundary, continue y/n" warning would do the trick. Perhaps, an > option to > silence this check would be useful also. > it's easy to

FLAC 0.8 is out. This version has gone through and passed the new (larger) test suite, so I'm much more confident in the encoder and decoder for all kinds of input. FLAC is much closer to an official version now. There are also some new features: I have added two metadata blocks: 1) a PADDING block, and 2) an APPLICATION block so third-party app developers can register for an ID and write

When I asked, | > If you're going to run flac -t later to test | > the .flac file, isn't it redundant to have verification on during | > encoding? Fearless Leader Ace Coalson responded, | yep. OK. | > If you know ... that -V was used | > during encoding and that flac reported "Verify OK," is there any | > reason to test the file? | nope, unless you suspect

Hi all, I have uploaded a source tarball to sourceforge for testing. See the news item in the HTML docs for the changes (or look here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/flac/flac/doc/html/news.html?rev=HEAD&content-type=text/html ) Download here: http://prdownloads.sourceforge.net/flac/flac-1.0.5_beta1.tar.gz?download The standard test of 'configure &&

I've a small system that I use to support a number of churches. I provide web and email for them. My current server is running CentOS 6.3 with paired 1TB drives in a RAID1 configuration. It works well. One filesystem is very large, >500GB, and contains numerous large files: SQL, docs, church libraries in ebook and digital form, plus stored videos of church services. My problem is that

Hello , you've been written that file format is frozen. does this mean that i'll be able to play files, commpressed today, say, 1-2 years after? thereby the next question is coming. what kind of strategy do you plan to enable fast seeking? to write new seeking algoritm, or to add some data to .flac file. i ask of it because i want to write files on cd-r and so i'd like to know can i