I can't figure out why Toshiba is bothering with Type II PCMCIA. A 5GB Type II CF card would be very cool, and would have some serious utility, but there just aren't that many devices that have full-size PC-Card slots that need removable online storage like this.
(I remember drives the size of washing machines... now something the size of a credit-card is considered "full-size.")
OK, this isn't news. This machine (Cappuchino), and it's little brother the Espresso, have been mentioned half a dozen times going back to last April.
They're made by Saintsong in Taiwan, and the easiest place to get them in the states is iBuyPower.
ObLinux: iBuyPower builds these to order, and you can get them without an OS, including a $75 credit for the Windows Tax.
Even though this is old news, they' are very cool. I have a dozen Celeron 533 Espressos that I use to run slideshow presentations at trade shows, and it's incredibly cool to be able to a) carry 12 machines in a briefcase, and b) literally duct tape them to the wall behind the monitor. (we usually use flat-panels)
The 103/A03 writes DVD-R at 2x. But DVD is inherently a variable-speed format. The 2x is in reference to full-bit-rate, which is about 10 megabits/s. So, 2x is about 2.5 megabytes/second. 4.7GB at 2.5MB/s is 32 minutes.
Under 5 megabytes a second, sorry. You're wrong on this one.
Keep your units straight. DV is 25Mb/s, or 3.2MB/s. DVD tops out at 10Mb/s, or 1.2MB/s
Not to mention the fact that 16x DVD drives are all over the place...
Fine. 16 x 10Mb/s is still only about 6x DV, and you're limited to about 20 minutes per DVD, so you're changing media about three times as often to boot. I just can't see how it's worth archiving DV on DVD-ROM.
If the $/GB for DVD-R drops below that of MiniDV tape then it _might_ be worth looking at, but the hassle factor is still high.
A great point - however if you are doing editing/post with this DV, pulling it off the miniDV tapes everytime you need something would be a pain. Storing a series of raw scenes on a DVD-R would let you keep all the data online, but not taking up your hard drive.
Probably not worth it, really. DV is 25Mb/s, DVD is 10. So you need at least a 4xDVD-ROM for DVD-R to be any faster than DV. The fastest DVD-ROM read speed I've seen is 10x, and you know that these speeds are peak, just like a CD-ROM drive. So we triple the media cost, spend time burning DVD-ROMs, and get, at best, a 4x speed improvement when it comes time to go get the footage again.
There are better ways. Keep your video on tape, log your footage carefully, and then keep the logs online and the tapes on the shelf. Batch capture works so well on modern NLEs that you can just feed the tapes in and let the machine do the work.
There's actually a very good reason why video and tape go hand in hand. Tape is excellent at capturing data with moderate bandwidth for extremely long durations. Sure, random access is cool, but video is by nature sequential.
The "SuperDrive" will be nothing more than a repackaged product from Philips, Sony or one of the several other DVD-R/CD-R drives that are just about to be released. And Apple won't have them before any PC parts house will.
Umm. Wrong. First of all. the SuperDrive is a Pioneer DVR-103. Second, the PC parts houses don't have them yet, and even Compaq isn't shipping them yet. But Apple is. I've had one for two months now. Expect it to be another two months before Pioneer ramps up to the point that they've saturated Apple and Compaq, then you'll start seeing them on pricewatch.
DVD-RAM specifically is a brain-dead standard. Sure, Hitachi has a camcorder that records directly to (3") DVD-RAMs, but then Sony has a camcorder that records directly to MD-Data2 and that's not going to go anywhere either.
But what you're looking for is DVD-R, and subsequently DVD-RW.
The drives are shipping now, though Apple is consuming 100% of the supply. The drive in question is the DVR-103/DVR-A03, and it can record DVD-R and DVD-RW. Compaq will be shipping the drives soon, and you'll also start seing them in external FireWire enclosures in the next couple of months.
To your specific questions:
All I want to do is dump and/or mix raw mini-DV footage from my digicam onto recordable DVD media.
Remember that DVD-Video is MPEG2, and DV is not. (DV is more closely related to a series of JPEG frames) This means that there will be substantial encoding time if you want to make these discs playable in set-top DVD players.
If all you want to do is archive the DV footage...leave it on the DV tapes. DVD-Rs have only now come down to $10 for a 4.7GB disc, while MiniDV tapes are about $6 for 13GB of storage. I don't know anything about the archival characteristics of DVD-R media, but tape is a known quantity, and since it's digital, you can "refresh" your archive periodically.
Better yet, I'd like to be able to take that little DV tape and load it into a mini DV drive (is it 4mm DAT?) on my DVD system, and shoot more movies while I'm saving footage to DVD media.
You still have the encode time issue above. MiniDV is not 4mm DAT, but Sony does (did? I keep seeing closeouts) make a deck that fits in a 5.25" drive bay. It's called the DRV-100. Internal or not, the interface is still Firewire, so you're better off with an external deck.
I'd also like to make backups of my VMWare guest OS virtual disks to DVD.
No problem. The drive is also a CD-RW machine, so it's a "small matter of software" to get it working burning DVD-ROMs. Toast is already there on the Mac.
This whole bundle sells for about $2/foot in 500' reels, which is about a house worth of wiring. If you're going to put cabling directly in the walls (as opposed to the excellent suggestions for going with conduit) then this is the stuff to use.
Given the installed infrastructure, I think emerging technologies are going to be centered around getting more speed out of CAT-5 and MMF. Heck, my new G4 has a 1000Base-TX port...CAT-5 again.
Myself, I'm cheap. So I've just been running 2xCAT-5 and 2xRG-6 everywhere I go, more if I need it. I live in a single-story house with a crawlspace, so it's easy to go below and pull more wire if I need it.
Add 802.11b for connectivity to the couch, hammock, and john, and you're set.
As for the kitchen machine, I really like the idea of mounting a Webplayer upside-down under the cabinets.
I've been using these (under the EspressoPC name, yes, slashdot found them for me a year ago) at tradeshows for some time.
While it isn't a mobile machine, it is a portable machine.
Think about it. If you're like 90% of the laptop users out there (myself included), you take your laptop to work, where you plug it in to a real keyboard, mouse and monitor, then carry it home, where you plug it in to a real keyboard mouse, and monitor.
So tell me why I'm carrying four pounds of LCD, keyboard and battery, when I all I need to carry is one pound of CPU and HD?
First of all FireWire is 400Mb/s. Yes, you can run full, uncompressed SMPTE270 video over FireWire.
The worst-case broadcast bit rate for HD is 19.4Mb/s. HD is broadcast as MPEG2, so it is compressed up the ying-yang. So is Digital Cable/DSS. That 270Mb/s D1 tape gets squashed to 2-6Mb/s for that "Digital Picture" we pay so much for.
DV is usually 25Mb/s. (I say "usually", Panasonic DVCPRO has bit rates up to 100Mb/s, but that's somewhat non-standard)
My impression of the 16 9 Time product is that it encapsulates the HD bitstream in DV frames. A clever hack to be sure, but it's enough to make the DV decks happy.
As to doing data backup to your DSR-20, remember that tape has dropouts. You'd need to do a fair bit of FEC to make that backup useful. Also, the nature of video is such that all the design decisions for DV were made in favor of isochrony over data integrity. Better to let some blocks through than freeze for a few frames. This has been gone over here before, as well as on the linux1394 discussion lists.
First of all, all of these devices are recording the compressed stream, not doing reltime encoding. This works just like the once-and-future DVHS decks, and the Panasonic PV-HD1000 would happily record HD MPEG2.
Camcorders are a different problem, and Apotsy is quite correct that realtime MPEG2 is harder than the DV codec, which is essentially JPEG with some interleaving to distribute tape dropouts.
That said, realtime MPEG2 is very real, and has been for some time now. In recent memory, realtime MPEG2 was expensive ($50k and 2RU in '98, $5k on a PCI card more recently) but Sony has recently released a MiniDisc camcorder that does MPEG2 encoding. MSRP is $2499, but the first MiniDV cameras cost that two years ago too.
The reason you won't find HD MiniDV anytime soon is that until the HD sets break out of the volume/price chicken-and-egg problem, you won't be able to sell HD cameras, because nobody will have anything to watch the tapes on.
The 16 9 Time hack is beautiful because it produces a relatively open bitstream. But the Hollywood/Tokyo axis has another round of DVHS players coming...you thought DIVX was bad, wait until you get a load of DVI/HDCP.
REAL HD is limited to 19.4Mb/s for broadcast, because that's what the 8VSB transport can carry. Uncompressed HD can be ungodly huge, but that has nothing to do with broadcast or CATV, only studios and post.
As you point out, uncompressed SD is 270Mb/s, but remember that REAL SD is 6MHz wide, and you're not going to tell me that AM and ColorBurst gets you 45 bits/Hz.
You broadcast guys should pay attention to what happens when your signal leaves the studio. It's a jungle out here.
why have an expensive device that can only receive mp3s over a network
You don't get it.
I have something like 35GB of MP3's. I don't want to have to replicate that 35gigs everywhere I want to listen to music. Wireless isn't up to MP3 bandwidth yet (not even Ricochet), so local storage is a necessary evil for portable devices. But at home, I have a LAN. This is why man invented file servers.
More to the point, the Rio/Dell Receiver has better DACs than any sound card ever will (and probably better than many SPDIF-input home theater receivers), and more importantly no moving parts. I don't want the whirr of fans or the whine of hard disks interfering with serious listening. And at high bitrates with good encoders, MP3s can be worthy of serious listening.
OK, so I'm completely spoiled by the empeg and empeg's other product, the Rio/Dell Receiver.
But the bottom line is this thing sucks.
The UI is slow and often can get behind what's actually happening, so it will show one track title while it's playing another.
The desktop software is entirely adequate for managing a 64MB flash-based player that might hold all of twenty tracks, but just doesn't cut it for a player that could hold two thousand. You have to add files one directory at a time (no drag-and-drop of/home/mp3) and I had a bunch of problems that make me think you can't have two tracks with the same title on the player at the same time.
It takes an eternity to boot, and the boot time gets longer as you add more tracks to the drive.
You can easily kill a set of batteries just carrying it in your bag, since the "lock" switch is read by software. The offshoot of this is that it boots up half-way, reads the lock switch, and shuts down.
The audio quality is mediocre, and the headphone drive is pathetic, even before you turn on EAX. Trying to use any of the EAX (DSP) features will cost you about 10dB of volume, which makes headphones unusable without an external amp.
To be fair, some of this could be fixed in firmware, and I haven't kept up with the updates since v1.75. You do wonder about a product that's initial release was v1.73, though.
And yes, Ji Luo does an excellent job of paying attention to the customers in the creative.* fora.
-Z
Of course, an older gcc is provided as 'kgcc' so that you can compile your kernels.
Without actually tweaking the Makefiles to deal with it. I know that 2.2.18 fixes this, but...
I finally got the time to build a new server for the house about the time that RH7 hit.
Now, leaving aside that adding an additional IDE controller is ungodly painful (hedrick's patches won't apply cleanly to the sources in the distro, and exactly what kernel options should I pass to probe a PnP PCI card?), I couldn't get the new kernel to build. Now I've built a few kernels, so I tried a few things.
Maybe the patches hosed me...reinstall the source RPM....nope.
OK, so I've selected some impossible combination of options... make mrproper ; make dep ; make clean ; make bzImage and just lean on CR through the config, accepting all the defaults...nope.
That's when I gave up for the night. I didn't figure out the the kgcc thing until I followed this story's link into bugzilla.
I know, I know...RTFREADME, but I think I'd make sure that kernels would build "out of the box" before I released a major upgrade to a major distro.
US Octane ratings are the average of the Research Octane Number (RON) and the Manufacturers Octane Number (MON). I don't fully understand the difference, but in general the RON is 2-3 points higher than the average number you see at the pump. In Europe, they only use the RON, so their 91 octane is the equivalent our mid-grade 89 octane. (I've never seen anything lower than 87 at the pump here, but I'm in CA)
As for this story: It's MIPS, not ARM, yes, it is Samba, and yes, it's self-hosting. Oh, and it is Apache, and Cobalt did a pretty nice job with the web management.
They work great for their intended purpose, but get a little wonky if you try to do things that the web-gui can't do. But you can always give up and put NetBSD on it.
It is legal for you to d/l an mp3, *only if you own the song already* but who the hell actually does this?
Aargh! Leaving aside for the moment that this is exactly what the BeamIt case is about...
What if (drum roll) the RIAA doesn't control the content? What if independent artists create the content on their own? Obviously this is the sort of thing that the RIAA/MPAA/et al are trying to prevent, and they're doing it by attacking the technological means that circumvent their distribution schemes.
There's a lot of legal content at mp3.com that the RIAA doesn't control, and that's exactly why the RIAA has been villifying mp3.com.
-Zandr
Re:Why not just use the Crusoe as a G4?
on
Darwin on Crusoe?
·
· Score: 2
IF they could just modify the pinouts of the Crusoe to conform with their sockets... They'd have a pretty cool setup.
Umm, have you looked inside a G4, or any recent mac, for that matter? the CPU not socketed, exactly, it's on a daughtercard.
The obvious route for a non-Moto Apple machine would be to build a daughtercard with the alternate CPU. Crusoe is an obvious choice, but there are others.
No speculation on how difficult a task this would be, since it would just be speculation. I will point out, however, that you can put a G4 into the "Processor Direct Slot" on Macs as far back as the 6100, and in the slot for the L2 cache on later machines. So if it's instuction-compatible, as Crusoe could become, it's possible to do great things for existing hardware.
In fact, if Apple doesn't do this themselves, someone else ought to.
A more interesting question, though, is whether this would help anything. Isn't IBM building the Crusoe? Doesn't IBM make G4's? Or was the supply problem because IBM isn't online with the G4 yet, leaving Moto as the sole source?
The Ultimate Compression Algorithm?
on
RIAA Sues MP3.com
·
· Score: 5
On the face of it, MP3.com is really stretching the notion of fair use. There's a different way to look at this, though. It's some strained logic, but stay with me here...
It's pretty clear that if you were actually uploading the data, then RIAA most likely lose this suit. MP3.com would be operating a remote backup server, and nothing more.
But you aren't uploading the data to MP3.com...or are you? Forgive me if I get details wrong, but I seem to recall reading about compression systems based on Huffman coding, where the Huffman tree is predetermined and not transmitted. Common symbols are replaced by smaller symbols, based on a predetermined scheme. It's nominally a substiution cipher, substituting smaller symbols for larger ones.
By now you can see where I'm going. Beam-It uploads very highly compressed copies of your CDs. The compression works by replacing a known symbol (the audio data on the CD) with a much smaller one. (the same catalog number that CDDB uses)
If MP3.com's lawyers can explain that to the judge, they might have a chance.
Spamcop has got to be the most worthless thing I've ever seen. Just about any ISP of any size is blocked according to their site. That and they can't tell the difference between spam and just regular email.
Well, yes. I sure as hell wouldn't use it for filtering mail, but it does serve as a nice header parsing tool, and the "cut-out" addresses are useful.
Slashdot Mirror
I can't figure out why Toshiba is bothering with Type II PCMCIA. A 5GB Type II CF card would be very cool, and would have some serious utility, but there just aren't that many devices that have full-size PC-Card slots that need removable online storage like this.
(I remember drives the size of washing machines... now something the size of a credit-card is considered "full-size.")
-Zandr
Do any of you even look at the articles? This is no different than the Trek or K2 Jettas we got in the states, without the blatant branding.
There's no info at all on the MP3 player, but I'd bet it's part of the "mini computer."
Which is [drum roll please] an HP Jornada. Look carefully.
And since GSM is the norm in Europe, I'm quite certain that the bundled PDA uses the bundled phone.
Which means that the cool innovation here is...
A car kit for the Jornada 540.
At least NetBSD is working on a port.
OK, this isn't news. This machine (Cappuchino), and it's little brother the Espresso, have been mentioned half a dozen times going back to last April.
They're made by Saintsong in Taiwan, and the easiest place to get them in the states is iBuyPower.
ObLinux: iBuyPower builds these to order, and you can get them without an OS, including a $75 credit for the Windows Tax.
Even though this is old news, they' are very cool. I have a dozen Celeron 533 Espressos that I use to run slideshow presentations at trade shows, and it's incredibly cool to be able to a) carry 12 machines in a briefcase, and b) literally duct tape them to the wall behind the monitor. (we usually use flat-panels)
-Zandr
The 103/A03 writes DVD-R at 2x. But DVD is inherently a variable-speed format. The 2x is in reference to full-bit-rate, which is about 10 megabits/s. So, 2x is about 2.5 megabytes/second. 4.7GB at 2.5MB/s is 32 minutes.
Under 5 megabytes a second, sorry. You're wrong on this one.
Keep your units straight. DV is 25Mb/s, or 3.2MB/s. DVD tops out at 10Mb/s, or 1.2MB/s
Not to mention the fact that 16x DVD drives are all over the place...
Fine. 16 x 10Mb/s is still only about 6x DV, and you're limited to about 20 minutes per DVD, so you're changing media about three times as often to boot. I just can't see how it's worth archiving DV on DVD-ROM.
If the $/GB for DVD-R drops below that of MiniDV tape then it _might_ be worth looking at, but the hassle factor is still high.
Actually, the article is talking about miniDVD, which is a full UDF DVD with 720x480 MPEG2. Essentially a DVD-Video disc written on CD-R[W] media.
Works in some players, but requires significantly more than the 2x spindle speed of SVCD.
-Zandr
A great point - however if you are doing editing/post with this DV, pulling it off the miniDV tapes everytime you need something would be a pain. Storing a series of raw scenes on a DVD-R would let you keep all the data online, but not taking up your hard drive.
Probably not worth it, really. DV is 25Mb/s, DVD is 10. So you need at least a 4xDVD-ROM for DVD-R to be any faster than DV. The fastest DVD-ROM read speed I've seen is 10x, and you know that these speeds are peak, just like a CD-ROM drive. So we triple the media cost, spend time burning DVD-ROMs, and get, at best, a 4x speed improvement when it comes time to go get the footage again.
There are better ways. Keep your video on tape, log your footage carefully, and then keep the logs online and the tapes on the shelf. Batch capture works so well on modern NLEs that you can just feed the tapes in and let the machine do the work.
There's actually a very good reason why video and tape go hand in hand. Tape is excellent at capturing data with moderate bandwidth for extremely long durations. Sure, random access is cool, but video is by nature sequential.
-Zandr
The "SuperDrive" will be nothing more than a repackaged product from Philips, Sony or one of the several other DVD-R/CD-R drives that are just about to be released. And Apple won't have them before any PC parts house will.
Umm. Wrong. First of all. the SuperDrive is a Pioneer DVR-103. Second, the PC parts houses don't have them yet, and even Compaq isn't shipping them yet. But Apple is. I've had one for two months now. Expect it to be another two months before Pioneer ramps up to the point that they've saturated Apple and Compaq, then you'll start seeing them on pricewatch.
DVD-RAM specifically is a brain-dead standard. Sure, Hitachi has a camcorder that records directly to (3") DVD-RAMs, but then Sony has a camcorder that records directly to MD-Data2 and that's not going to go anywhere either.
But what you're looking for is DVD-R, and subsequently DVD-RW.
The drives are shipping now, though Apple is consuming 100% of the supply. The drive in question is the DVR-103/DVR-A03, and it can record DVD-R and DVD-RW. Compaq will be shipping the drives soon, and you'll also start seing them in external FireWire enclosures in the next couple of months.
To your specific questions:
All I want to do is dump and/or mix raw mini-DV footage from my digicam onto recordable DVD media.
Remember that DVD-Video is MPEG2, and DV is not. (DV is more closely related to a series of JPEG frames) This means that there will be substantial encoding time if you want to make these discs playable in set-top DVD players.
If all you want to do is archive the DV footage...leave it on the DV tapes. DVD-Rs have only now come down to $10 for a 4.7GB disc, while MiniDV tapes are about $6 for 13GB of storage. I don't know anything about the archival characteristics of DVD-R media, but tape is a known quantity, and since it's digital, you can "refresh" your archive periodically.
Better yet, I'd like to be able to take that little DV tape and load it into a mini DV drive (is it 4mm DAT?) on my DVD system, and shoot more movies while I'm saving footage to DVD media.
You still have the encode time issue above. MiniDV is not 4mm DAT, but Sony does (did? I keep seeing closeouts) make a deck that fits in a 5.25" drive bay. It's called the DRV-100. Internal or not, the interface is still Firewire, so you're better off with an external deck.
I'd also like to make backups of my VMWare guest OS virtual disks to DVD.
No problem. The drive is also a CD-RW machine, so it's a "small matter of software" to get it working burning DVD-ROMs. Toast is already there on the Mac.
-Zandr
Didn't the Condor do this sort of thing ten years ago?
The condor is the giant black aircraft in the photo on the left.
It's now in the Hiller museum in San Carlos. Sorry, no better linkage...
-Zandr
The "smart home" folks who do this for a living refer to this as "structured wiring," so that's probably the right search term.
The best solution I've seen is a single bundle that contains:
2x 4pr CAT-5
2x RG-6 (75ohm Coax)
2x 1pr 16ga speaker wire
2x Multi-Mode fiber
This whole bundle sells for about $2/foot in 500' reels, which is about a house worth of wiring. If you're going to put cabling directly in the walls (as opposed to the excellent suggestions for going with conduit) then this is the stuff to use.
Given the installed infrastructure, I think emerging technologies are going to be centered around getting more speed out of CAT-5 and MMF. Heck, my new G4 has a 1000Base-TX port...CAT-5 again.
Myself, I'm cheap. So I've just been running 2xCAT-5 and 2xRG-6 everywhere I go, more if I need it. I live in a single-story house with a crawlspace, so it's easy to go below and pull more wire if I need it.
Add 802.11b for connectivity to the couch, hammock, and john, and you're set.
As for the kitchen machine, I really like the idea of mounting a Webplayer upside-down under the cabinets.
I've been using these (under the EspressoPC name, yes, slashdot found them for me a year ago) at tradeshows for some time.
While it isn't a mobile machine, it is a portable machine.
Think about it. If you're like 90% of the laptop users out there (myself included), you take your laptop to work, where you plug it in to a real keyboard, mouse and monitor, then carry it home, where you plug it in to a real keyboard mouse, and monitor.
So tell me why I'm carrying four pounds of LCD, keyboard and battery, when I all I need to carry is one pound of CPU and HD?
-Z
No problem.
First of all FireWire is 400Mb/s. Yes, you can run full, uncompressed SMPTE270 video over FireWire.
The worst-case broadcast bit rate for HD is 19.4Mb/s. HD is broadcast as MPEG2, so it is compressed up the ying-yang. So is Digital Cable/DSS. That 270Mb/s D1 tape gets squashed to 2-6Mb/s for that "Digital Picture" we pay so much for.
DV is usually 25Mb/s. (I say "usually", Panasonic DVCPRO has bit rates up to 100Mb/s, but that's somewhat non-standard)
My impression of the 16 9 Time product is that it encapsulates the HD bitstream in DV frames. A clever hack to be sure, but it's enough to make the DV decks happy.
As to doing data backup to your DSR-20, remember that tape has dropouts. You'd need to do a fair bit of FEC to make that backup useful. Also, the nature of video is such that all the design decisions for DV were made in favor of isochrony over data integrity. Better to let some blocks through than freeze for a few frames. This has been gone over here before, as well as on the linux1394 discussion lists.
First of all, all of these devices are recording the compressed stream, not doing reltime encoding. This works just like the once-and-future DVHS decks, and the Panasonic PV-HD1000 would happily record HD MPEG2.
Camcorders are a different problem, and Apotsy is quite correct that realtime MPEG2 is harder than the DV codec, which is essentially JPEG with some interleaving to distribute tape dropouts.
That said, realtime MPEG2 is very real, and has been for some time now. In recent memory, realtime MPEG2 was expensive ($50k and 2RU in '98, $5k on a PCI card more recently) but Sony has recently released a MiniDisc camcorder that does MPEG2 encoding. MSRP is $2499, but the first MiniDV cameras cost that two years ago too.
The reason you won't find HD MiniDV anytime soon is that until the HD sets break out of the volume/price chicken-and-egg problem, you won't be able to sell HD cameras, because nobody will have anything to watch the tapes on.
The 16 9 Time hack is beautiful because it produces a relatively open bitstream. But the Hollywood/Tokyo axis has another round of DVHS players coming...you thought DIVX was bad, wait until you get a load of DVI/HDCP.
REAL HD is limited to 19.4Mb/s for broadcast, because that's what the 8VSB transport can carry. Uncompressed HD can be ungodly huge, but that has nothing to do with broadcast or CATV, only studios and post.
As you point out, uncompressed SD is 270Mb/s, but remember that REAL SD is 6MHz wide, and you're not going to tell me that AM and ColorBurst gets you 45 bits/Hz.
You broadcast guys should pay attention to what happens when your signal leaves the studio. It's a jungle out here.
why have an expensive device that can only receive mp3s over a network
You don't get it.
I have something like 35GB of MP3's. I don't want to have to replicate that 35gigs everywhere I want to listen to music. Wireless isn't up to MP3 bandwidth yet (not even Ricochet), so local storage is a necessary evil for portable devices. But at home, I have a LAN. This is why man invented file servers.
More to the point, the Rio/Dell Receiver has better DACs than any sound card ever will (and probably better than many SPDIF-input home theater receivers), and more importantly no moving parts. I don't want the whirr of fans or the whine of hard disks interfering with serious listening. And at high bitrates with good encoders, MP3s can be worthy of serious listening.
That silence alone is worth the $299.
-Z
OK, so I'm completely spoiled by the empeg and empeg's other product, the Rio/Dell Receiver. But the bottom line is this thing sucks. The UI is slow and often can get behind what's actually happening, so it will show one track title while it's playing another. The desktop software is entirely adequate for managing a 64MB flash-based player that might hold all of twenty tracks, but just doesn't cut it for a player that could hold two thousand. You have to add files one directory at a time (no drag-and-drop of /home/mp3) and I had a bunch of problems that make me think you can't have two tracks with the same title on the player at the same time.
It takes an eternity to boot, and the boot time gets longer as you add more tracks to the drive.
You can easily kill a set of batteries just carrying it in your bag, since the "lock" switch is read by software. The offshoot of this is that it boots up half-way, reads the lock switch, and shuts down.
The audio quality is mediocre, and the headphone drive is pathetic, even before you turn on EAX. Trying to use any of the EAX (DSP) features will cost you about 10dB of volume, which makes headphones unusable without an external amp.
To be fair, some of this could be fixed in firmware, and I haven't kept up with the updates since v1.75. You do wonder about a product that's initial release was v1.73, though.
And yes, Ji Luo does an excellent job of paying attention to the customers in the creative.* fora.
-Z
Just do an "export CC=kgcc" and you should be fine.
Which is more or less my point.
It's very simple to fix, so why wasn't it?
Compiling kernels is very basic functionality, guys.
Of course, an older gcc is provided as 'kgcc' so that you can compile your kernels.
Without actually tweaking the Makefiles to deal with it. I know that 2.2.18 fixes this, but...
I finally got the time to build a new server for the house about the time that RH7 hit.
Now, leaving aside that adding an additional IDE controller is ungodly painful (hedrick's patches won't apply cleanly to the sources in the distro, and exactly what kernel options should I pass to probe a PnP PCI card?), I couldn't get the new kernel to build. Now I've built a few kernels, so I tried a few things.
Maybe the patches hosed me...reinstall the source RPM....nope.
OK, so I've selected some impossible combination of options... make mrproper ; make dep ; make clean ; make bzImage and just lean on CR through the config, accepting all the defaults...nope.
That's when I gave up for the night. I didn't figure out the the kgcc thing until I followed this story's link into bugzilla.
I know, I know...RTFREADME, but I think I'd make sure that kernels would build "out of the box" before I released a major upgrade to a major distro.
-Zandr
US Octane ratings are the average of the Research Octane Number (RON) and the Manufacturers Octane Number (MON). I don't fully understand the difference, but in general the RON is 2-3 points higher than the average number you see at the pump. In Europe, they only use the RON, so their 91 octane is the equivalent our mid-grade 89 octane. (I've never seen anything lower than 87 at the pump here, but I'm in CA)
Once again, Slashdot doesn't read Slashdot.
How about:
http://slashdot.org/articles/99/ 10/13/132216.shtml
or even
http://slashdot.org/articles/99/ 12/08/136255.shtml
Where Hemos acknowledges that slashdot doesn't read slashdot on this very topic.
As for this story:
It's MIPS, not ARM, yes, it is Samba, and yes, it's self-hosting.
Oh, and it is Apache, and Cobalt did a pretty nice job with the web management.
They work great for their intended purpose, but get a little wonky if you try to do things that the web-gui can't do.
But you can always give up and put NetBSD on it.
-Zandr
It is legal for you to d/l an mp3, *only if you own the song already* but who the hell actually does this?
Aargh! Leaving aside for the moment that this is exactly what the BeamIt case is about...
What if (drum roll) the RIAA doesn't control the content? What if independent artists create the content on their own? Obviously this is the sort of thing that the RIAA/MPAA/et al are trying to prevent, and they're doing it by attacking the technological means that circumvent their distribution schemes.
There's a lot of legal content at mp3.com that the RIAA doesn't control, and that's exactly why the RIAA has been villifying mp3.com.
-Zandr
IF they could just modify the pinouts of the Crusoe to conform with their sockets... They'd have a pretty cool setup.
Umm, have you looked inside a G4, or any recent mac, for that matter? the CPU not socketed, exactly, it's on a daughtercard.
The obvious route for a non-Moto Apple machine would be to build a daughtercard with the alternate CPU. Crusoe is an obvious choice, but there are others.
No speculation on how difficult a task this would be, since it would just be speculation. I will point out, however, that you can put a G4 into the "Processor Direct Slot" on Macs as far back as the 6100, and in the slot for the L2 cache on later machines. So if it's instuction-compatible, as Crusoe could become, it's possible to do great things for existing hardware.
In fact, if Apple doesn't do this themselves, someone else ought to.
A more interesting question, though, is whether this would help anything. Isn't IBM building the Crusoe? Doesn't IBM make G4's? Or was the supply problem because IBM isn't online with the G4 yet, leaving Moto as the sole source?
On the face of it, MP3.com is really stretching the notion of fair use. There's a different way to look at this, though. It's some strained logic, but stay with me here...
It's pretty clear that if you were actually uploading the data, then RIAA most likely lose this suit. MP3.com would be operating a remote backup server, and nothing more.
But you aren't uploading the data to MP3.com...or are you? Forgive me if I get details wrong, but I seem to recall reading about compression systems based on Huffman coding, where the Huffman tree is predetermined and not transmitted. Common symbols are replaced by smaller symbols, based on a predetermined scheme. It's nominally a substiution cipher, substituting smaller symbols for larger ones.
By now you can see where I'm going. Beam-It uploads very highly compressed copies of your CDs. The compression works by replacing a known symbol (the audio data on the CD) with a much smaller one. (the same catalog number that CDDB uses)
If MP3.com's lawyers can explain that to the judge, they might have a chance.
-Zandr
Spamcop has got to be the most worthless thing I've ever seen. Just about any ISP of any size is blocked according to their site. That and they can't tell the difference between spam and just regular email.
Well, yes. I sure as hell wouldn't use it for filtering mail, but it does serve as a nice header parsing tool, and the "cut-out" addresses are useful.