similar to: (no subject)

My comments: ;) >hmm, I'm thinking we could >spec out an ETREE metadata >block that you could use. Yes, I think this is a good idea. I'd like to incorporate this a s much as possible as the "FLAC Standard" if it's OK with you guys, since ideally FLAC will be the etree.org format of choice, replacing Shorten. >> Filesize compressed >> >this is

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

First of all, this is my first post so please go easy if I'm a little off-topic. Just let me know nicely off-list. Thanks! As Mike already knows, I am currently trying to develop a plug-in for playing Shorten files over Audion on the Macintosh platform. When I proposed this to him to get some information on contacting the right people, he mentioned you guys and I need a little info.

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 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

Pyxml/xmlproc is being used in tools/xen/xm/xenapi_create.py but is unmaintained for several years now. xmlproc is used only for validating XML documents against a DTD file. This patch replaces the pyxml/xmlproc based XML validation with code based on lxml, which is actively maintained. Signed-off-by: Stephan Peijnik <spe@anexia.at> diff -r 6e0ffcd2d9e0 -r 7082ce86e492

Josh Coalson wrote: > I've been thinking about this, and here's what I > came up with. This kind of dovetails into the > discussion Mike Wren started about the etree > header. > > I was thinking about defining a FREEFORM metadata > block which may be of arbitrary size. The only > mandatory field would be a (say, 32-bit) id of > the owner. In your case, you

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

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:

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

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'. > >

Hello, all, I'm a newby to FLAC who is used to making .txt source files for his SHN discs. :) I made my first secure EAC > WAV> FAC file days ago and am trying to get proper "source file" info figured out.. First question; how do you make paragraph seperations in the Tag Config. > Comments field? Better yet, can someone provide me with a < 1MB FLAC file sample

* Josh Coalson (xflac@yahoo.com) wrote: > I'm kind of swamped today so I'll answer what I can get > away with until tonight: > > --- Joshua Haberman <joshua@haberman.com> wrote: > > The most interesting questions to me are ones you didn't address: > > > > 1. Will Ogg FLAC become the default manifestation of the FLAC codec? > > If not, why

----- Forwarded message from Wolfgang Rohdewald <wolfgang@rohdewald.de> ----- Date: Sun, 03 Oct 2004 19:24:38 +0200 From: Wolfgang Rohdewald <wolfgang@rohdewald.de> Resent-From: Wolfgang Rohdewald <wolfgang@rohdewald.de> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Bug#274700: flac: --export-vc-to should quote strings containing spaces Package: flac

Why do some of you use FLAC for lossless encoding? I've done some test and MAC filesizes were always smaller. I don't seem to see what the problem is. CH4R1ie --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word

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

> > 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

Great to hear that things are going smoothly, Josh. My $.02 is that it is worth making 110% sure that you/we've tweaked the codec for speed/compression as much as can be done *before* 1.0, since we're really not under any kind of deadline. Sure, it would be nice to get it out the door, but why not have it rival Shorten and Monkey's right from the start? I'm *still* working on

Hi there, I'm using libvorbis in my program and need to encode to target bitrate. I know libvorbis prefer to use quality scale but I can't use it. I've found something at faq http://vorbis.com/faq/#quality *For now, quality 0 is roughly equivalent to 64kbps average, 5 is roughly 160kbps, and 10 gives about 400kbps. Most people seeking very-near-CD-quality audio encode at a quality