Slashback: Embed, Dougal, FireWire
Reality is just an illustrator's concept. In regards to the speculative piece about what animals will look like in the future, Ken Colangelo writes: "The author of After Man was Dougal Dixon, not Dougal Adams. He's got a pretty long track record as an amazing bio-illustrator.
He had, at one point, spoken of a book he was working on called "Man After Man" I believe. This would discuss what man would evolve into. In any case, I am probably his biggest (only?) fan and would appreciate it if you'd tell slashdot to correct his name ... This guy clearly needs to be working in speculative evolution again, now that computer graphics have caught up to his abilities. Animal Planet just doesn't seem to be that great at it."
A bit more on that secret FireWire, since it's no longer secret. cwill1004 writes "As was speculated yesterday, it turns out that Apple is indeed including a new higher-speed FireWire on its new laptops. Dubbed IEEE1394b, it appears to be primarily for external storage devices. One article on the Storage Supersite says that LaCie, Maxtor, SmartDisk, and Indigita have already hopped on board. The best part: IEEE1394b is backwards compatible, and available on both Mac and PC."
Perl undoes simplicity itself.
ljb writes " I've re-written Tom Murphy's
'embed' bit-flipping program
in Perl. At 76 characters (shorter than a standard
80-character width terminal line),
I believe this qualifies as a Perl "one-liner". Heck, you could even fit this on an old IBM punchcard
(ignoring character set limitations). Here's the Perl script --
$/=\4;map{?OS/2?|$f&&$f++==2?$c-=2+vec($_,0,32)/4: ++$c||s/../\0\0/s;print}<>"
So get distributed crackin' ... scubacuda writes "On. Off. Now it's on again? According to PC World (et al), The Neo Project again tackles the challenge of cracking Microsoft's encryption key."
It's good, weird, but good.
My only problem with Dougal is his alleged theft from Barlowe. Still, his stuff is primo.
The Dougal Dixon link is bad, or it's just been slashdotted I think.
The new Firewire is signal compatible, but it has a new plug. So you need adapters to plug old cables into the new PowerBooks.
Haven't heard of why they did this, but I guess they had a reason. Hopefully a good one.
The new Powerbooks that have the new Firewire (Firewire800, if you will) also have a standard Firewire port. Both original and Firewire800 devices can be plugged in at once, but as you posted, there is also an adapter to convert the newer port to original Firewire.
Surprisingly, I haven't seen much said about the possibility of much faster Firewire RAIDs. Using the adapter to have the Firewire800 port act as a second Firewire bus would get some great speeds.
BareFeats does a lot of work testing Firewire RAID setups. There should be some tests there once the new Powerbooks are more readily available.
Twelve fingers or one, its how you play. ~Gattaca (Vincent)
Well, there's 10 gigabit Ethernet, and Intel are now sampling a card that supports it.
I was in Best Buy, or The Good Guys the other day, and happened to see a display of stereo equipment. The manufacturer was pitching the product line as using Firewire to interconnect all the devices. Personally I think this is a great design. Suddenly each device has a power cord, and a single data cable. And then the reciever has a "hub" built in. FAR less spaghetti behind the system, FAR less opportunities for noise to leak into the wiring, etc.
"Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs." P.J. O'Rourke
His one-liner doesn't seem to update the checksum? There is a checksum someplace in there.
How do I know this interesting fact? Because last year I tried writing my own one-liner, but couldn't squeeze it down to one line because of the checksum.
Here's what I came up with at the time, which according to diff produces identical output to the C code:
121 bytes if you take out the newlines. And any slashdot-inserted spaces.
No, I have no idea how it works any more. The code is placed in $_, the '-' is not as it seems, eval() runs the code in $_, and that's all I can tell you. Welcome to Perl!
The general idea is that you only use lossy interframe compression once, when you're all done editing and are producing final output. Otherwise, you get artifacts from multiple compression/decompression passes.
Misunderstanding on your part when you use the word 'capture'.
"This is a windows only issues, but why is it that the DV manufacturers decided in their infinite wisdom to make it so you could only record in one format (DV)?"
DV is the format the recording is stored on the tape. There *is* no 'capture' method when you transfer to the PC. Now, what you want is a program that converts from the DV stream into your codec of choice *before* it is stored onto the drive.
GPL Deconstructed
DV manufacturers decided in their infinite wisdom to make it so you could only capture in one format (DV)?
Um, what would you expect a DV manufacturer to make?
will I be able to software compress a DV stream as I capture it?
A DV stream is already digital, you don't need to "capture" it. And it's already compressed (it's similar to MJPEG). And there are actually two DV formats (well, more than that if you count NTSC vs PAL), 25 Mb/sec (the usual) and higher quality 50 Mb/sec used in high end professional gear.
Oh, and not all Firewire video is DV. There are some applications (notably machine vision) where you don't want any compression artifacts, so you run an uncompressed data stream over the wire. Requires specialized gear.
my question to the 1394b creators
All of which has nothing to do with 1394b. DV over 1394a only uses 100 Mb/sec of bandwidth, and a lot of that is empty packets (the main constraint is the timing, if you're sending real-time video you use an isochronous channel on the firewire). 1394b probably (I haven't looked at that part of the spec) means you can run more isochronous channels at the same time, for simultaneous real-time video streams, but I don't know for sure. Either way the DV format doesn't change.
-- Alastair