For years I've been batching up my new CDs to rip all at the same time. Sometimes, this means doing a couple a month. Other times, like this year, it means catching up with 12 months of backlog. And while my ripping habits likely are uninteresting to readers, what I've learned over the years may be helpful.
Years ago I installed the 'abcde' port, and update it from time to time. Having it in-place, and configured, makes all the difference in the world. I use cdparanoia as my reading method since it is the slow but reliable choice.
There are many silly process things that make things go faster. First, make sure that you have all the CDs in the cases that you have stacked up. A few days before I start to rip, I go through the stack to make sure that none are on walk-about. Next, grab a bottle of windex, and a lint-free cloth. Wash each of the CDs, assembly line style. Sometimes I only do this for the discs that fail, but often times it helps things go so much faster that it can be worth the up front time.
Once I have the discs prepped, I pick a time that I'm not using my laptop too much to do the ripping. For me, this is often my work day, since I look at it from time to time for email and irc messages only. My laptop DVD player isn't the best in the world, but that's OK. The ones that rip quickly, I don't have to do anything about. The ones that are scratched badly, I put aside for later. The easy ones are boring, since abcde makes them boring, so I'll not describe the process much further. Each disc takes about 10 minutes to rip and transcode them.
The scratched discs are more of a challange. I've used a lot of players over the years. They vary widely in their quality. The cheapo player I have in my laptop copes with most of the discs. If I see too many + signs in a disc, I'll set it aside for later. Here, too many is 'more + than spaces in the output' when I look over at the screen several times. Or if there's any 'V' indications on any of the tracks. These usually take longer to do anyway, and get in the way of breezing through the easy CDs. Each year, I have maybe 5 discs that are stubborn, out of maybe 30 that I do. Long term averages are that 1 in 10 newly purchased 'used' disc show this. Discs that have been knocking around in the car for months are more likely to suffer from this as well. Really stubborn ones are more like 1 in 100, but more on that in a bit.
I have a special CD-ROM (not DVD) that I use for the scratched discs. Of all the drives I've tested/used over the years, this one has the best success rate by far of any of them. This one happens to be a 52x/20x/20x IDE drive branded by HP I got at Target, of all places, several years ago. I can take a disc that has 20-30 V's on it with my cheapo laptop setup, and sometimes get a good read with this player. Often, the discs just read quickly, and that's the end of it.
Sometimes, however, the disc is badly damaged and is that it is very slow. I was able to rescue a Moxie Froovis CD and a Phil Collin's greatest hits CD with this drive. But it took a week each of reading. When the drive is connected to a server, it doesn't matter so much that it is doing this. The CPU time isn't all that great during the week, so it doesn't interfere with the normal server operations. I look in on them once an hour at first, then once a day until the songs are done. Since I rarely have more than one or two of these a year, the extra time isn't that big a deal.
At one point, I had a dozen laptops with CD Roms that I could use for ripping. I thought this would be great, since I could do so many in parallel. It turns out that the CD Rom drives in these were even cheaper than the one I'm using today. I spent so much time running between the laptops that I didn't get any work done. And the CPUs in these boxes were all, at best, squirrel powered, so they couldn't handle the encoding as well as my 2GHz HP Pavilion laptop does now. At the time, I just did it serially on the server I had (which was a 666MHz Intel), and changed it every hour or two. I could still run it remotely, so I wasn't running back to the server room except to change a disc.
Today, with iTunes and other music places online, the art of coaxing bits off of audio CDs seems a bit passe. However, it is still something I find I'm doing a lot. Used CDs cost almost nothing, compared to $1/song for iTunes. Plus, format shifting is so much easier with audio CDs than with iTunes. Also note: I'm not talking about sharing my collection over the internet, just making the archival copies, and format shifted copies, as allowed by law and court decision. I still have most of the original CDs, and those I no longer have had been destroyed by my two-year-old when he was younger... But that's a story for a different time...
20081216
20081214
DLink DIR-615 Rev C1
Today I saw that Office Depot had a DIR-615 on sale for $40.00. It was a new hardware revision: C1. I took a chance that it was a new non-Ubimax based router. I'm glad I did, at least so far.
The router is based around the Atheros AR9130 CPU. This is MIPS based, so there's a good chance that I'll be able to put FreeBSD onto it. We'll see how it goes.
I'll report more when I get a chance to examine the RAM and Flash parts, as well as map out the serial port to see what is reported there. Stay tuned.
The router is based around the Atheros AR9130 CPU. This is MIPS based, so there's a good chance that I'll be able to put FreeBSD onto it. We'll see how it goes.
I'll report more when I get a chance to examine the RAM and Flash parts, as well as map out the serial port to see what is reported there. Stay tuned.
20081213
More CardBus fixes
After I committed my previous set of CardBus fixes, reports came in about interrupt storms, first with 16-bit cards, and later with 32-bit cards. These have been corrected in my latest fixes. We always act the CSTS interrupt when we see it. In addition, I've changed the acking of the 16-bit ExCA register to only happen when there's a "R2" or 16-bit card in the slot. Otherwise we now skip it. Hopefilly, this will help the shared interrupt case as well by eliminating some PCI bus cycles...
The CSTS bit is interesting. It is the least well documented bit in the CardBus standard. It is unclear when it fires from reading the standard, but seems to be related to the card finishing its reset sequence. How this differs from the power-up interrupt, I'm not sure. I think we could further optimize the bring up of CardBus cards with it.
In addition, I noticed there's a READY bit in the ExCA CSC register. We're currently doing busy waits to bring up the cards, including a couple of millisecond long DELAYs. I'll have to look into the prospect of using that interrupt to get around these issues there.
Finally, I'm looking in earnest at the Alchemy Au1550 CPU for the OpenMicroServer port I'm doing. I've noticed that it uses a 16-bit PC Card interface. Maybe I'll finally need to rewrite the old PCIC driver from OLDCARD to make use of it (snagging the exca routines to make that easier). The OpenMicroServer has a CF card attached to it.
The CSTS bit is interesting. It is the least well documented bit in the CardBus standard. It is unclear when it fires from reading the standard, but seems to be related to the card finishing its reset sequence. How this differs from the power-up interrupt, I'm not sure. I think we could further optimize the bring up of CardBus cards with it.
In addition, I noticed there's a READY bit in the ExCA CSC register. We're currently doing busy waits to bring up the cards, including a couple of millisecond long DELAYs. I'll have to look into the prospect of using that interrupt to get around these issues there.
Finally, I'm looking in earnest at the Alchemy Au1550 CPU for the OpenMicroServer port I'm doing. I've noticed that it uses a 16-bit PC Card interface. Maybe I'll finally need to rewrite the old PCIC driver from OLDCARD to make use of it (snagging the exca routines to make that easier). The OpenMicroServer has a CF card attached to it.
20081204
Cardbus Fixes
I just checked into the tree some CardBus fixes. The biggest change was to the power-up sequence, as well as transitioning to using filters for the card change events. These two changes are somewhat intertwined, unfortunately, since the latter exposed some holes in the former. In a nutshell, we now register a filter for the card status change events. This means we can mark the card as bad right away before any additional interaction can happen to the card. We defer doing anything about the badness for a little bit (basically until the machine is idle enough for the cardbus kernel thread to run). The interlock mechanism is also much ligher weight, having moved from mutexes and CVs to simple msleeps. Fast interrupts require some care to get right, so I hope I've gotten it all right. The move is dictated by what you can and cannot do in a fast interrupt handler.
Before making these changes, my atheros card would often reset for no reason. After these changes, I've not had it reset until I started using a kernel without the changes. I'm not sure why this would make such a big difference, and I hate mysteries. They indicate that there's something I don't understand, which I also hate. I'd be interested to see if I still see this when the fully integrated code is committed and looped back (I have several trees, and I most frequently run an unmodified kernel from svn, but sometimes also run one of these trees). There's a small chance that one of my other local changes could be the cause, but given what they are it seems doubtful. Still, a good datapoint if it is.
In addition, these fixes add a retry option for the BadVcc errors that we'd see sometimes. These are annoying on some machines, and often times the best way to get around them was to reload the driver. They don't happen at all on TI based chipsets that I've seen (at least more recent ones). Instead, they were confined to the Ricoh chipsets. Since I switched my laptop a couple of years ago, I haven't seen them. These changes post-date the change, but have been tested lightly on another Ricoh laptop that I have. They've been heavily tested on the TI laptop. They are based only on the description of the problem in the NetBSD PR, since the implementations are so different for the different BSDs in this area.
Finally, I did some comment tweaking and shuffling. I also managed a style change or two. These should have absolutely no effect on the running code, but hopefully help the reader of the code understand it better. Past experience has shown that these types of commits are most likely to provoke comment, even though the other two parts of my commits are actually quite a bit more important.
Oh, why the flurry of commits? I was low on disk space, so I thought I'd go clean up. 11MB free just isn't enough. So I was looking around and discovered I still had a CVS tree and was going to blow it away. I did a final update just to see what changes I had. I'm glad I did, since I found these, and a few others. I still have more local changes there than I realized. Sometimes I guess it is good to run out of disk space and go on a cleaning spree? It also makes for smaller backups when you don't have top copy 5GB of /usr/obj and kernel build trees...
Before making these changes, my atheros card would often reset for no reason. After these changes, I've not had it reset until I started using a kernel without the changes. I'm not sure why this would make such a big difference, and I hate mysteries. They indicate that there's something I don't understand, which I also hate. I'd be interested to see if I still see this when the fully integrated code is committed and looped back (I have several trees, and I most frequently run an unmodified kernel from svn, but sometimes also run one of these trees). There's a small chance that one of my other local changes could be the cause, but given what they are it seems doubtful. Still, a good datapoint if it is.
In addition, these fixes add a retry option for the BadVcc errors that we'd see sometimes. These are annoying on some machines, and often times the best way to get around them was to reload the driver. They don't happen at all on TI based chipsets that I've seen (at least more recent ones). Instead, they were confined to the Ricoh chipsets. Since I switched my laptop a couple of years ago, I haven't seen them. These changes post-date the change, but have been tested lightly on another Ricoh laptop that I have. They've been heavily tested on the TI laptop. They are based only on the description of the problem in the NetBSD PR, since the implementations are so different for the different BSDs in this area.
Finally, I did some comment tweaking and shuffling. I also managed a style change or two. These should have absolutely no effect on the running code, but hopefully help the reader of the code understand it better. Past experience has shown that these types of commits are most likely to provoke comment, even though the other two parts of my commits are actually quite a bit more important.
Oh, why the flurry of commits? I was low on disk space, so I thought I'd go clean up. 11MB free just isn't enough. So I was looking around and discovered I still had a CVS tree and was going to blow it away. I did a final update just to see what changes I had. I'm glad I did, since I found these, and a few others. I still have more local changes there than I realized. Sometimes I guess it is good to run out of disk space and go on a cleaning spree? It also makes for smaller backups when you don't have top copy 5GB of /usr/obj and kernel build trees...
Moving towards board files
I've spent a little bit of time implementing the start of board files for the arm port. The initial push has been for the at91 subport only, and many improvements could be made to this. I've written up my initial thoughts on this on the FreeBSD wiki FreeBSD Arm Boards. It could use much improvement, I'm sure.
One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share.
I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides).
I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here.
One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share.
I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides).
I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here.
20081202
Cassio Fiva's screen dead
I was very fortunate enough to get a Casio Fiva MCP-205 given to me in 2000. I've used this laptop for years. I built Mozilla on it once, and melted the frame around the LCD! This resulted in a new warning in the Mozilla build instructions. Since Casio is a Japanese company, and I got this as the result of my contacts in Japan at the time, my news of melting the Fiva spread like wild fire there. Recently, when I was in Tokyo for AsiaBSDCon people were asking me about it.
I've been using this laptop to do background builds, as a mobile terminal, firewire debugging platform, etc since I got it. Recently, i had put the laptop on the shelf. I'd not used it in the past 6 months or so for a variety of reasons. Last night I thought I'd give it a spin again, since I need a nice mobile platform. Sadly, while it was in storage the screen was cracked. I cannot get any text on the screen at all. I don't have the VGA cable so I could keep this laptop around as a server, since there's no console access. I cannot find an LCD to replace it, but I imagine that it would be expensive. More expensive than a modern netbook, which would be better for the FreeBSD project anyway...
It is sad to see this laptop give up the ghost. Every time I used it, I was reminded of the good times in Japan. I'll hang onto the laptop for a little while on the off chance I can turn up a replacement LCD, but I fear it is dead.
I've been using this laptop to do background builds, as a mobile terminal, firewire debugging platform, etc since I got it. Recently, i had put the laptop on the shelf. I'd not used it in the past 6 months or so for a variety of reasons. Last night I thought I'd give it a spin again, since I need a nice mobile platform. Sadly, while it was in storage the screen was cracked. I cannot get any text on the screen at all. I don't have the VGA cable so I could keep this laptop around as a server, since there's no console access. I cannot find an LCD to replace it, but I imagine that it would be expensive. More expensive than a modern netbook, which would be better for the FreeBSD project anyway...
It is sad to see this laptop give up the ghost. Every time I used it, I was reminded of the good times in Japan. I'll hang onto the laptop for a little while on the off chance I can turn up a replacement LCD, but I fear it is dead.
Subscribe to:
Posts (Atom)