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 5 copies, only to find out 3 days later that halfway through one track, one channel cut out for the remainder of the track. So, two ways that FLAC is far superior to Shorten.. incorporated checksums, and much improved error recovery. I see etree.org users as more of archivists than music fans, since we place so much emphesis on bit-for-bit accuracy. Using a codec that makes this job easier for us is a very welcome thing! If you (or anyone else on this list) can keep track of selling points for FLAC over other current (and future) lossless codecs, I would like to compile a list, since I will be running propaganda to convert etree users to FLAC. It won't be an easy sell though. Hope everyone had a great weekend! Wren Josh Coalson wrote on 4/16/01 4:36 pm:>--- Mike Wren ><mikew@etree.org> wrote: >> ... >> >> I'm *still* working on >getting some etree.org >developers to help out, but I >> think as a whole, etree'ers >are stuck in their Shorten >frame-of-mind >> (creating workarounds for >an old and very limited >codec). >> >One thing that might change >some minds is shorten's lack >of error recovery. I don't >know how much users have >analyzed the format, but if >you are using for archiving >you should definitely know >that if even one bit is >damaged in the shorten file, >the minimum damage is that >the rest of the data for the >channel is bad. Shorten >cannot recover from errors >because it relies on the >correct decoding of the >previous frame to prime the >predictor, whereas FLAC >does not. > >Josh > > >_____________________________ >_____________________ Do You >Yahoo!? >Get email at your own >domain with Yahoo! Mail. >http://personal.mail.yahoo.c >om/ > >_____________________________ >__________________ Flac-dev >mailing list >Flac-dev@lists.sourceforge.n >et >http://lists.sourceforge.net/ >lists/listinfo/flac-dev
> ... > So, two ways that FLAC is far superior to Shorten.. incorporated > checksums, > and much improved error recovery. > > I see etree.org users as more of archivists than music fans, since we > place > so much emphesis on bit-for-bit accuracy. Using a codec that makes > this job > easier for us is a very welcome thing! > > If you (or anyone else on this list) can keep track of selling points > for > FLAC over other current (and future) lossless codecs, I would like to > compile a list, since I will be running propaganda to convert etree > users to > FLAC. It won't be an easy sell though. >I think making the whole process easier will be key. Some people just don't like to change even when the change is for the better. As far as features go, the two you mentioned are important, plus better compression ratios. I will be tackling speed before 1.0 with some assembly, and I expect that flac will eventually get the same ratios as shorten much faster, as well as better compression for the same speed. Right now FLAC already gets usually 5% more compression than Shorten for about a 2.5x runtime increase (at least with my tests). But making it easy will be just as important. As far as command-line usage, flac requires less work since the MD5 and seektables are built-in. It doesn't restore funky WAV metadata (just the basic fields) and it doesn't try to reproduce the original date/time like shorten does because the unix utility 'touch' is just as effective. It has a Winamp2 plugin with seeking and ID3V1 tag recognition. So what else do you guys have written on top of shorten that can be migrated to FLAC? And what things (like custom metadata) could you take advantage of to make trading easier? I know you had some rough ideas before, but are you ready to spec out your own APPLICATION block? Josh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
> 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. Anything > that > you guys have as far as how playback of the FLAC standard could be > played back via WinAmp or similar programs (someone's gotta be > working > on this, it's a must-have to help convert us SHN archivists) would be > greatly appreciated.Great to have you on board. We already have a Winamp2 plugin written, so that's a good place to see how to interface with the library. There is also an XMMS plugin which is slightly different. You can get the latest source release in a tarball from here: http://sourceforge.net/project/showfiles.php?group_id=13478 To summarize how to interface with the decoding library: basically there are two decoding layers. The lowest layer is the stream decoder, where you write the callbacks for reading and writing, and the file decoder, which wraps around the stream decoder. The file decoder handles most of the details and also has functions for seeking. So in a plugin you will typically create an instance of a file decoder, provide a callback function that the file decoder will call when it wants to give you decoded data, then you just repeatedly ask for a frame of decoded data.> Also, if there are any other Macintosh users out > there I'd like to hear some ideas about what needs to be included and > how we might get this accomplished. Also, I have currently adopted > the > new MacOS X which is completely Unix-based (Free BSD 4.2 I believe) > but > I know very little about Unix programming. From what I've seen > around, > there is very little difference between an app compiled for some > flavors > of *nix and the way it needs to be compiled. If anyone has any ideas > > how to compile the FLAC utilities to the MacOS X platform, please > contact me ASAP. >The first thing I would try is to get a basic Gnu setup (gcc/gnumake), then untar the source release, then run the configure script and then make. Are you familiar with gnu configure already? The README file in the top directory has basic instructions but I can give you more detail if you like. Josh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
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. Anything that you guys have as far as how playback of the FLAC standard could be played back via WinAmp or similar programs (someone's gotta be working on this, it's a must-have to help convert us SHN archivists) would be greatly appreciated. Also, if there are any other Macintosh users out there I'd like to hear some ideas about what needs to be included and how we might get this accomplished. Also, I have currently adopted the new MacOS X which is completely Unix-based (Free BSD 4.2 I believe) but I know very little about Unix programming. From what I've seen around, there is very little difference between an app compiled for some flavors of *nix and the way it needs to be compiled. If anyone has any ideas how to compile the FLAC utilities to the MacOS X platform, please contact me ASAP. Thanks for listening! -Ryan http://db.etree.org/schpider AIM: Schpider98 On Sunday, April 22, 2001, at 09:05 PM, Mike Wren wrote:> 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 5 copies, only to find out 3 days later that halfway > through one track, one channel cut out for the remainder of the track. > > So, two ways that FLAC is far superior to Shorten.. incorporated > checksums, > and much improved error recovery. > > I see etree.org users as more of archivists than music fans, since we > place > so much emphesis on bit-for-bit accuracy. Using a codec that makes > this job > easier for us is a very welcome thing! > > If you (or anyone else on this list) can keep track of selling points > for > FLAC over other current (and future) lossless codecs, I would like to > compile a list, since I will be running propaganda to convert etree > users to > FLAC. It won't be an easy sell though. > > Hope everyone had a great weekend! > > > Wren > > > > Josh Coalson wrote on 4/16/01 4:36 pm: > >> --- Mike Wren >> <mikew@etree.org> wrote: >>> ... >>> >>> I'm *still* working on >> getting some etree.org >> developers to help out, but I >>> think as a whole, etree'ers >> are stuck in their Shorten >> frame-of-mind >>> (creating workarounds for >> an old and very limited >> codec). >>> >> One thing that might change >> some minds is shorten's lack >> of error recovery. I don't >> know how much users have >> analyzed the format, but if >> you are using for archiving >> you should definitely know >> that if even one bit is >> damaged in the shorten file, >> the minimum damage is that >> the rest of the data for the >> channel is bad. Shorten >> cannot recover from errors >> because it relies on the >> correct decoding of the >> previous frame to prime the >> predictor, whereas FLAC >> does not. >> >> Josh >> >> >> _____________________________ >> _____________________ Do You >> Yahoo!? >> Get email at your own >> domain with Yahoo! Mail. >> http://personal.mail.yahoo.c >> om/ >> >> _____________________________ >> __________________ Flac-dev >> mailing list >> Flac-dev@lists.sourceforge.n >> et >> http://lists.sourceforge.net/ >> lists/listinfo/flac-dev > > > _______________________________________________ > Flac-dev mailing list > Flac-dev@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/flac-dev
> So, two ways that FLAC is far superior to Shorten.. incorporated > checksums, > and much improved error recovery. >One thing I forgot to mention was the '-V' option, which allows you to encode/decode/compare at the same time to make sure that the created .flac file is correct. If you do the same thing with Shorten (3 commands) it will definitely run slower since you have to read and write to disk all the data multiple times, whereas with flac it's all done a frame at a time in memory. Josh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/