4 ms·

Oh well. :-) All turned out wonderful in the end. We never needed to re-rip the CDs after all. Apple took bulk-uploads the same as all the other companies.

by sivers 16y ago

Oh well. :-) All turned out wonderful in the end. We never needed to re-rip the CDs after all. Apple took bulk-uploads the same as all the other companies. An incredibly efficient way of delivering over 2 million songs+metadata from one company to another. A nice little collection of Ruby & PHP scripts on a stack of Linux servers & Windows encoding boxes did everything. Unfortunately I'm not allowed to open-source that software since I sold it.

pbhjpbhj 16y ago
>Apple took bulk-uploads the same as all the other companies. Wouldn't it have been cheaper and quicker to send a few hard drives with the data on by post?
- petsos 16y ago
  It wouldn't be cheaper for Apple. They would need a lot more employes to handle these hard drives.
  - pbhjpbhj 16y ago
    Really, with just music files on from known good sources in an already fixed format - I'm seeing them put it in a caddy, rip the files dumped from their app via antivirus scrubbers to a network drive or other local HDD and then [unfortunatley] chuck it in the bin. Would that be too hard? They'd perhaps need an intern for that as a short term project. After the initial c.900000 music file (100,000 albums) then uploading would probably be more feasible. 900000 tracks of 5MB (assuming lossy compression) at 10Mbps would take over 40 days of 24-7 uploading (not allowing for errors and outages and such). 10Mbps was still quite fast for uploads in 2003 I think (faster than the current average in the US according to DSLreports). S-ATA RAID0 write bandwidth was about 34MBps at the time, roughly 27 times faster than the network in-flow; I'll assume read was faster and so this is the limit for disk-to-disk transfer. Assuming shipping took a couple of days you'd expect to finish the transfer a month quicker. I'd be interested in how it would be cheaper for Apple for the initial round to accept uploads only, especially given this retards the lead time (to selling the tracks) by a month or more.
    - pbhjpbhj 16y ago
      I'm genuinely curious as it seems I'm totally wrong on this point and HN'ers have an obvious answer to why I'm wrong, could someone be so kind as to tell me what glaring error I'm making in my analysis. Much obliged.

by sivers 16y ago

pbhjpbhj 16y ago

>Apple took bulk-uploads the same as all the other companies. Wouldn't it have been cheaper and quicker to send a few hard drives with the data on by post?

petsos 16y ago
It wouldn't be cheaper for Apple. They would need a lot more employes to handle these hard drives.
- pbhjpbhj 16y ago
  Really, with just music files on from known good sources in an already fixed format - I'm seeing them put it in a caddy, rip the files dumped from their app via antivirus scrubbers to a network drive or other local HDD and then [unfortunatley] chuck it in the bin. Would that be too hard? They'd perhaps need an intern for that as a short term project. After the initial c.900000 music file (100,000 albums) then uploading would probably be more feasible. 900000 tracks of 5MB (assuming lossy compression) at 10Mbps would take over 40 days of 24-7 uploading (not allowing for errors and outages and such). 10Mbps was still quite fast for uploads in 2003 I think (faster than the current average in the US according to DSLreports). S-ATA RAID0 write bandwidth was about 34MBps at the time, roughly 27 times faster than the network in-flow; I'll assume read was faster and so this is the limit for disk-to-disk transfer. Assuming shipping took a couple of days you'd expect to finish the transfer a month quicker. I'd be interested in how it would be cheaper for Apple for the initial round to accept uploads only, especially given this retards the lead time (to selling the tracks) by a month or more.
  - pbhjpbhj 16y ago
    I'm genuinely curious as it seems I'm totally wrong on this point and HN'ers have an obvious answer to why I'm wrong, could someone be so kind as to tell me what glaring error I'm making in my analysis. Much obliged.