So I'm supposed to be on a plane tomorrow to Dallas so that I can swelter like a pig at departmental expense. I'd rather do this with some music of my choosing, but the Galaxy Nexus is not going to serve that purpose without a network connection in the air (Amazon Cloud Player probably wouldn't be happy with in-flight WiFi either, to say nothing of the rest of the passengers), so I picked up an 8GB SanDisk Sansa Fuze+ for $80 at Worst Best Buy on the way out of the office.
The Fuze+ is a 320x240 resolution ARM-based music and video player. At $80 (and this is a Best Buy price -- you can do a lot better), you should not expect much, and that's what you get: the screen is low resolution and has crummy angles, fonts are jaggy, the UI is laggy, the touch pad is wacky and the interface is crappy. But you also get a device that has a microSD card slot for expansion, supports lots of audio codecs (I prefer uncompressed music, and while it does not support AIFF, it does support uncompressed WAV and FLAC), has good sound (at least for FLAC), has decent battery life (about 18-24 hours of audio play on a charge depending on how much you have the screen on), charges over regular USB with a standard micro-USB port, and most important of all has USB Mass Storage support as well as Media Transport Protocol support. Heck, they even throw in an FM radio and a voice recorder.
Does it work with 10.4? Of course. In fact, with USB MSC support, it works on Linux too, and even works with good old Mac OS 9. Format the unit from its internal menu (do NOT format it from Disk Utility; you could brick it) to get rid of the stupid sample tracks it comes with, set it to Mass Storage mode from the internal menu, and plug it in. Create folders under Music and just copy your music over. You can create .m3u playlists as well which can reference any audio file, not just MP3s (older Sansa devices used the bizarre PLP/PLA format, but the Fuze+ does not support these anymore). The only stipulations are that the .m3u file must have DOS line endings (i.e., \r\n), should avoid referencing files outside of that folder, and must be EXTM3U format (i.e., the first line must be #EXTM3U\r\n). Don't use MacRoman; use Windows-1252. BBEdit can help you do this right. Put the playlist in the same folder with the music files it references and after you unmount and unplug it from the computer, the playlist and your new music will appear in the playlists screen along with any other playlists anywhere on the device (it will also find playlists in the Trash, so make sure you empty the Trash before you put it away). Play and enjoy. I wrote a little Perl script to turn my AIFF files into FLAC and construct the M3U playlists for me. ID3 tags are helpful, but they are not necessary.
Note that if you change the M3U playlist by hand from the Mac after you've already uploaded it to the device, the Fuze+ may not notice and might still play the songs in the old order. If that's the case, you'll have to remove that playlist and its files, unmount the device and let the Fuze+ discover they are gone, then remount the device, add them back and let the Fuze+ rediscover them. This is the only glitch I've found with this method.
Fortunately, if the built-in firmware is not sufficient for you, I am delighted to discover that not only is the Sansa Fuze+ supported by Rockbox, but that the Rockbox Utility used for installing it and managing its firmware still works fully with PowerPC 10.4. Great work, guys! Please note that as of this writing the Fuze+ port is still considered unstable and only mostly works, but it looks like it hasn't long to go before it becomes a regular version. I should also add that I have not done any testing of the Fuze+'s MPEG-4 video support, but I don't expect it to perform particularly well with that task and neither should you (it's not what I bought it for in any case).
ObTenFourFoxStuff. I discovered a memory leak in 22 which is due to our custom font code -- we do not use the CoreText/CGFont-based backend of Firefox any more for enumerating fonts, instead using good old ATSUI and converting ATS font references to CGFontRefs on the fly where needed. Well, it turns out we're leaking those synthesized references, and have been ever since 19 (17 is unaffected), but for some reason it's worse in 22. That fix will be part of 22.0.1 as well (issue 232). Again, it does not affect 17.0.x.
The death march to the new Australis interface continues inexorably in the bloodied halls of Mountain View. Instead of "ship in 25" it is currently "land in 25, ship in 26," and various intractable performance problems are making the probability of "land in 26, ship in 27" increase daily. One particularly serious performance issue was specific to 10.6, which alarms me that either Australis is not being written with 10.6 in mind or that it requires hardware assistance only available on 10.7 and up to be performant. Worst of all, the release drivers were perfectly willing to ship with that particular issue unresolved (though other improvements eventually mitigated it) which we should take as evidence of 10.6's shrinking window of support at the administrative level. The strong dependence on gradients is also going to make coding it up unfun, since 10.4 does not have the utility CGGradient class and requires lots of inconvenient CGShading workarounds. We'll deal with that as the dust starts to clear in the 25 timeframe.
The patches for 24 are all down and merged, but I haven't tried to build it yet. I'm actually scared to, frankly.
Sandisk is usually pretty good for compatibility. I used a Amiga 3000 to copy all my music to a Sansa Clip+ and had no problems. I later used a Mac to create a custom Rockbox layout for the Clip+ - using fonts I originally created for the Amiga.
ReplyDeleteCan you *really* discern between an MP3 file compressed with sufficiently high bitrate and the original CD source?
ReplyDeleteIs that a placebo effect? Can you perform some ABX testing to verify your perception?
If you can, then we (the LAME team) would certaninly want to hear from you *what* you can listen and describe it so that we can try to make it better.
I may have very bad ears and I mostly can' hear differences between the original recordings and the same thing compressed with LAME at quality level -V5 (or even -V6, which would give us lower bitrates).
I just encode things with -V4 to make them future proof safe, but I don't really expect my ears (and listening ability of artifacts) to become so better as I age.
Oh, that a lot of the music that I listen to is extreme metal, which is known to inflate the bitrates when compressing with variable bitrate, as it usually contains high frequency drums.
Can we not get into that here? This is about a music device that was easy to get working with old Power Macs running 10.4 and I'd prefer to keep it to that.
Delete