similar to: FlacPak

--- tech@bishop.dhs.org wrote: > On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > > Steve Lhomme wrote: > > > > > > You might try to contact the makers of FruityLoops. Right now > their > > > samples packs are in Ogg format (stored in a WAV IIRC). They like > open > > > and free formats (they also use the LAME encoder). >

On Wed, Nov 19, 2003 at 08:41:56AM -0700, tech@bishop.dhs.org wrote: > On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > > Steve Lhomme wrote: > > > > > > You might try to contact the makers of FruityLoops. Right now their > > > samples packs are in Ogg format (stored in a WAV IIRC). They like open > > > and free formats (they also

On Tue, Nov 18, 2003 at 08:34:05PM -0800, Josh Green wrote: > > Steve Lhomme wrote: > > > > You might try to contact the makers of FruityLoops. Right now their > > samples packs are in Ogg format (stored in a WAV IIRC). They like open > > and free formats (they also use the LAME encoder). > > I've thought of doing lossy compression before on instruments,

Curt Sampson wrote: > > > > I've thought of doing lossy compression before on instruments, > but I'd > > > > much rather stick to lossless, at least for now. > > Honestly, stick to lossless. I mean, to the point where you can get > your exact samples back. Sure, an S900 sample is not so great quality, > but having come from the era where I did the

On Mon, 2003-11-17 at 11:04, Josh Coalson wrote: > could you clarify your plan... are you thinking about > 1) encoding to a FLAC container and using metadata blocks > for everything that is not data? > 2) writing your own container? > > 1) seems kind of impractical to do in a general way. > I'm starting to also think that 2) is the best route. I was originally

I agree, but the idea behind the OGG formats is to build patent free codecs. Is FLAC really patent-free ? And does the OGG team agree to include FLAC in their specs ? smoerk wrote: > I agree. I think Ogg/Flac does not make sense, if it's not in the > official distribution. the benefits: > > - many ogg players could play flac > - flac could be integrated in oggenc (oggdrop)

On Wed, 19 Nov 2003, Josh Green wrote: > I am curious though how one would get around the problems of looping > with a lossy algorithm. When decoding a vorbis stream would one have > the same number of samples as you encoded? The problem with looping > arises if the loop points aren't the same sample values, resulting in > a click. Some sort of algorithm could be run around the

Thought I'd send an update on FlacPak a file format for compressing instrument files (although its more generically a method of compressing files containing binary and audio with most of the smarts being in the encoder file handlers). It uses zlib for compressing the binary data and FLAC (of course :) for compressing the audio. There is now a CVS tarball of libInstPatch which contains a

Hi All, What is the status of the oggpcm project? I'm investigation solutions to the following problem: losslessly encode double-precision mutli-channel timeseries data in a format that is compatible with free (libre) internet streaming technologies and that permits diverse metadata to be encoded with the stream. flac isn't suitable because it only supports integer data, lossy

For those who are interested in checking out my initial specification for the FlacPak format, I updated the web pages at: http://swami.sourceforge.net/flacpak.php The direct link to the specification notes: http://swami.sourceforge.net/flacpak_format.php For those who weren't reading the previous threads, FlacPak is a format being designed to handle compression of files containing binary and

I created a quick mini banner logo based on the flac logo and put it up for viewing (its not publicly linked yet). Let me know if this is ok with you, or if you would rather me come up with something original :) My only complaint about it, is that I like the font you used better. http://swami.sourceforge.net/flacpak.php Cheers. Josh Green

I sent a little mail some time ago asking if there was going to be an ogg pic-format, and you replied that PNG, MNG and JNG is good enough (sorry for this late answer btw).. But, consider this: The ogg video-format (tarkin ? where do you get these names from anyway ? :) ) needs a way to compress its frames. Are you going to use MNG for that ? :) .. If you had an ogg pic format, that format could

--- Josh Green <jgreen@users.sourceforge.net> wrote: > The audio data will be encoded with FLAC and thats where I have some > questions. My current thinking is to combine audio of the same type > together to minimize changing of parameters in the FLAC stream. Same > sample type being data that has the same number of channels and bit > width. There will also be cases where a

On Sun, Feb 16, 2003 at 01:05:06PM +0100, Miroslav Lichvar wrote: > On Sat, Feb 15, 2003 at 06:18:12PM -0700, David Bishop wrote: > > I'm attempting to add flac playback to my app, and would like a couple of > > pointers. First of all, I'm very much a "learn by seeing other people doing" > > sort of programmer, and would love a pointer to an open-source

samples in FLAC are always signed. they must be signed going into the encoder (flac converts unsigned samples to signed) and they come out of the decoder signed. Josh --- David Bishop <tech@bishop.dhs.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Followup to original question: how do I determine if a particular > flac file is > signed (and then, if

I posted to this list a couple years back and then again sometime a year ago about using Flac to compress SoundFont instrument files. I never got around to finalizing the specification for that project, and I have since realized that a more generic approach would be better. I registered the "SFFL" Sound Font FLAC application meta data ID. I would like to remove that, since it was never

On Aug 8, 2009, at 23:11, Didier Dambrin wrote: > Electronic music quite often doesn't leave a computer these days. > And it > mainly consists of drums, synths & vocals/effects. Drums are often > samples > sequenced at sample (not sub-sample) accuracy, thus repeated (of > course if > the song was post-resampled, there will be sub-sample times). Good point. I

Monkey's Audio lossless compressor (currently win32 only, free but not open-source except decoder) author is thinking to implement a kind of audiophile-quality lossy compression which would filter "noise bits" that are hard to encode lossless but which are (or should be) inaudible and thus improve lossless compression (avg. 300-450kbps). I think that implementing something like this

hi flac-dev list! I see, when compressing CD-audio tracks, I can reach up to 60% (ratio = 0.6x) of the original WAV file after compression. I was wondering if the FLAC codec could become as good as reaching 50% of the original WAV file in the future or if we are already at the (almost) maximum compression possible? thx -------------- next part -------------- An HTML attachment was scrubbed...

On Sat, Jun 20, 2020 at 4:08 AM Tom Bishop <bishoptf at gmail.com> wrote: > +1 Streams is not for a production workload, if I wanted that I can easily > deploy an Arch instance if I want or need a rolling distro (it's not Redhat > etc but still). If Redhat wanted CentOS to be released near the same time > line they could help make that happen, although that wouldn't be