Art Alexion on 26 Feb 2009 09:49:48 -0800 |
On Thursday 26 February 2009 12:14:42 pm Walt Mankowski wrote: > On Thu, Feb 26, 2009 at 12:08:14PM -0500, gabriel rosenkoetter wrote: > > I actually question the sanity of doing the flac->mp3 processing on > > the fly all the time, which entails a non-trivial memory and CPU hit. > > It may work okay if there's only one or two readers, but it can't > > scale without some fairly clever pre-fetch and (fast) disk caching. > > That said, it's perfect for what it's intended to do (but don't > > imagine that you could use this to drive, for example, 25 listening > > stations in a record store without throwing some beefy hardware at > > it). > > You're also going to take a big hit the first time you try to sync it > with a new device, but you'd take that anyway. I'm a little curious > how you avoid taking that hit every time you sync -- if it just uses > timestamps, that's fine. But if it uses something like an md5 > checksum, it's not going to work all that well. Unless it somehow persists in memory after the first conversion, it seems it will have to transcode the flac files every time you access it for loading on a media player. I don't think it is meant for driving streaming audio, just the media player thing. Amarok has a transcode plugin that provides this function as well. I have no idea which is more efficient. I sometimes use the transcode script to load OGG files on a iPod as the iPod only plays MP3 or AAC (and some other Apple formats.) The mp3fs doesn't seem to handle sources other than FLAC. I assume it can be tweaked. Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|