[Flac-dev] the road to 1.0...

[Ryan Sinnwell]

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 at 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 at lists.sourceforge.n
>> et
>> http://lists.sourceforge.net/
>> lists/listinfo/flac-dev
>
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/flac-dev