I know the list has been pretty quiet lately but that is actually a good thing I think... I've been putting the finishing touches on 1.0, resolving the last remaining bugs, and nothing new seems to have cropped up The release should be this week. After that I will probably switch to a new method for releases. Stable ones will be released as normal, but beta releases in between may only be released as source and will be clearly marked as beta. If people really want binary beta releases then I would probably compile in -V as a default, which you would have to manually turn off with -V-. I've checked in the majority of the changes. The only thing left are some recent 3dnow asm contributions and russian translation of the docs, which I will check in today. And the PIC problems with the assembly are still unresolved (more on that later). Let me know if I've missed anything. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
--- Miles Egan <miles@caddr.com> wrote:> Are there rpms for flac available?I'm not aware of any official maintainers but supposedly the gstreamer guys (http://gstreamer.sf.net) have a spec file for it. I am going to look into it in the next couple of days but when 1.0 comes out I'm sure RPMs will pop up pretty quickly. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Are there rpms for flac available? -- miles
--- Matt Zimmerman <mdz@debian.org> wrote:> My only complaint right now is not FLAC's fault, but you might have > some ideas. > I have configured grip <http://www.nostatic.org/grip/grip.html> to > use FLAC to > encode CD tracks, so I can just select oggenc or flac from a menu and > everything works. That is, everything except the progress bar. grip > was > designed for mp3 and other fixed-bitrate encoding methods, so its > progress > meter works by checking the size of the output file and comparing it > to the > final expected size (calculated based on the bitrate). > > It would be nice if FLAC (and other encoders) supported some standard > method > for indicating progress, so that things like this could work. This > could be as > simple as periodically printing a line with only an ASCII decimal > number to be > interpreted as a percentage, or as fancy as a separate library that > could > display progress data in many different styles (human- and > machine-readable).This would definitely be useful; I think if you get ripper developers on board it is pretty easy to implement what they agree to. Grip might be a good place to start since Mike seems to be pretty responsive. The new one-line stats in flac has an easily parseable percentage number for each file. I don't know if the carriage-return- without-linefeed messes up the ripper but I think it would be possible to write a little wrapper script around flac that reformats the data to what the ripper expects. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
On Mon, Jul 16, 2001 at 11:24:43AM -0700, Josh Coalson wrote:> I've checked in the majority of the changes. The only thing left are some > recent 3dnow asm contributions and russian translation of the docs, which I > will check in today. And the PIC problems with the assembly are still > unresolved (more on that later). Let me know if I've missed anything.My only complaint right now is not FLAC's fault, but you might have some ideas. I have configured grip <http://www.nostatic.org/grip/grip.html> to use FLAC to encode CD tracks, so I can just select oggenc or flac from a menu and everything works. That is, everything except the progress bar. grip was designed for mp3 and other fixed-bitrate encoding methods, so its progress meter works by checking the size of the output file and comparing it to the final expected size (calculated based on the bitrate). It would be nice if FLAC (and other encoders) supported some standard method for indicating progress, so that things like this could work. This could be as simple as periodically printing a line with only an ASCII decimal number to be interpreted as a percentage, or as fancy as a separate library that could display progress data in many different styles (human- and machine-readable). What do you think? -- - mdz