I am employed writing software for a company that makes robots that are used to help do physical therapy for stroke patients. We have been covered by
ABC
and
BBC, among others. (We have robots in Canada, but I know of no coverage by
CBC.) Anyway, some folks might wonder if these robots are replacing physical therapists (bad robots!). But this kind of physical therapy involves repetition of movement that is both boring and physically strenuous for therapists, so a tireless precise robot is a fine idea for this task. And the robot works somewhat like a very fancy force feedback joystick controlling a video game, which is fun for stroke patients, who are more used to therapy tasks like "squeeze the rubber ball" and "try to walk while holding the parallel bars."
The hacking is fun, a combo of real time control and game programming, and it's gratifying to be involved in software work that is more beneficial to humanity than the usual "moving bits from here to there."
i agree that the author of the article explains lossless compression nicely enough, i'm just saying that lossless compression doesn't make sense for a portable music player at this time. In five years, when we can store an infinite amount of data on a keychain fob, this might not matter, but practically speaking, for now, space matters.
that said, you note that we are talking about turning a digital master into a home recording. if you are going to look at that question, why not consider providing all the master information to the home user? i think you could provide a large amount of it if you were going to waste 30 megs on a 3-minute song (let's say you give the home user 8 channels plus the ability to tweak all the settings on a sound mixing board, with other signal processing also? With a "revert" button, of course. I think that would be a much nicer than 30 megs of bloated.wav. What, you say, most people would just make a mess. Well, we already have bass, treble, volume, and balance control. That's just a poor set of controls to do what we really want.
Is lossy compression really like 8-track tape? Well, they are both lossy. But besides being lossy, 8-track tape was read-only (practically speaking - I don't remember anyone recording 8-track tapes). It was terribly mechanical and prone to head misalignment in typical (in-car) use. Most importantly, you can't get an exact copy from an 8-track tape, like you can from any non-DRM digital medium. This, in particular, is an essential difference between tape (especially cheap tape) and a bag of bits.
You ask about what I meant by "always losing data. let's say that a master saved input from 32 microphones each sampling at 100khz, 128 bits per sample. 50 megabytes per second, 3000 per minute (if I multiplied correctly). A lot now, someday, not a lot. From that minute of music, we are choosing 10 megs today for our so-called "lossless" compression. Do we get a better representation of the signal by choosing a lossless signal or a lossy one, given the same amount of space? When I said "we are always losing data," I was suggesting that when you realize that you are always losing data (because the 30 meg.wav is not an accurate represesntation of the master), that you will get a better signal from 30 megs output from a good lossy codec than 30 megs output from a lossless codec.
i was working for a unix startup, circa 1984. we have all our motorola 68k workstations netted together with fat ethernet. one of the machines is the mail/netnews/uucp hub, and it had some small 5 1/4 inch disk with 40 meg or something on it. The machine's disk was full, and it needed to be cleaned up by hand. i logged into the console, which was spewing system error messages. i looked for a copy of dired, a bsd standalone directory editor, that would make my task a bit simpler. the system didn't have dired, but it had emacs dired mode, which was close enough (famous last words).
i was familiar with standalone dired, not with the emacs mode. i su to root, cd to/tmp and start deleting files. disk-full error messages are streaming away, messing up the dired screen display. at some point, it must must have asked me, "are you sure," and i probably typed yes.
a minute or so later, it types starts complaining about missing a whole bunch of stuff in/bin. what had happened, is that emacs dired listed . and.. as files that i might want to delete, and i asked it to delete them (when the screen was askew from constant disk full system error messages). bsd dired did not have this feature that provided the opportunity to delete . and.., so when i asked to delete/tmp/.. , it went to / and started deleting merrily away, and died after it deleted/bin/rm, which it must have been using to do the actual deletions.
we didn't have the presence of mind to just mount the disk on another machine, i don't remember why, maybe just trauma, but in those days, most workstations had just one disk.
we looked at/bin and saw that we had/bin/sh and/bin/uudecode. (the files in/bin were stored in alphabetical order)./bin/ls was gone (ls before rm), but we got a directory listing with "echo *" which was a shell built-in. we used/bin/sh to type in a shell script with while and read and echo to create an ascii text file that was a uuencoded binary of cat, I think, so we could read from a 5 inch floppy or something.
we eventually brought the system back to life. it was not my finest hour.
Before saving a digital song to the hard drive, software can shrink it in size by 50 percent or so just by using a shorthand notation that takes up a little less space for any repetitive patterns in the 0's and 1's.
The author of this article shows no understanding of signal processing or how music data is compressed, so his conclusions are silly. Comparing lossy music compression to 8-track tapes is silly.
He complains about lossy compression, but saving signal data (like photos or music) is always a lossy process, because there no exact digital representation of them. You decide to save a certain amount of data, let's say, 3 megabytes (or 30 megabytes) for 3 minutes of music, and then you decide what to put in those megabytes. You will always be able to get more/better data into the same space if you use signal processing compressors than if you just use uncompressed samples saved at some sampling rate and width per sample.
People who don't understand signal processing have a problem with the concept of "lossy." Signal processing engineers are not idiots. They don't design algorithms saying "I want to lose information and make a lower quality signal." They're just saying, "I want to save the data in this much space, which part of the data do I want to lose?" If you're saving recorded music, you are always losing data. The goal is to lose the least important part. The idea is slightly subtle, and it is apparently confusing to some people.
"Fahrenheit 9/11" turned on the box office heat in its first day in theaters breaking single-day records at the two New York City theaters where it played.
How important is it that they stuffed lots of people into two theaters for one day? Not to comment on whether or not I agree with the politics of his movie, but this lead paragraph reminds me that Moore is often inclined to twist and spin the truth to suit his point of view, which, at least for me, weakens his message.
support for variable width fonts. this would require some finessing tabs, and perhaps an easy way to switch to a fixed width font. while you're at it, support unicode and other fat fonts.
ability to search for text (with a regexp, of course) in the output window.
I think plan 9 has these, but I use unix/linux, and
acme
/
wily don't cut it for me as handy *nix ui's. They seem wonderful in theory, but I could never get wily working on my *nix boxes in practice.
I am already working on a portable beowulf cluster based on this technology. Im finding that the 32 cent stamps work best...
Though the Honeywell 16 series was designed as an I/O processor for he internet, they were also ganged together (not quite beowulf) and used as timesharing machines. I hacked the
1648
for a while, i think it was two 516's (one for OS and one for as many user jobs would fit in 32 K), and a 316 for I/O.
Well I agree maybe a carrying handle would be useful since it is 16 lbs, but other than that keep the latptop/notebook form factor. It is superior to the lunchpail.
With three nicely spaced holes, you could use it for bowling.
The reason is, the theoretical perfect tuning does not actually render a musically correct scale.
I think your comment applies equally to this retensioning device as it would to a system that retuned with digital filters, but it doesn't address my question of whether you could just do it all digitally without retensioning.
why not just keep the strings at one tension and alter the tunings by processing the output wave forms? this would be simpler, and electric guitarists already run their signals through other effects boxes. (i'm not a guitarist or a signals engineer, i'm just curious.)
Re:I've got one reason to choose Linux over UNIX-S
on
SCOoby Snacks
·
· Score: 1
Encumbered? That's chutzpah. The famous Yiddish definition of chutzpah is when a man kills his parents and then throws himself at the mercy of the court because he is an orphan.
note that the bible is full of gnurdly specifications if not actual tech docs, the earliest one perhaps, concerning the
building of a boat. (scroll down to 6:14.)
in order for worm/spammers to profit from spam, they have to put some link back to themselves in the spam, don't they? doesn't that make them a bit easier to track down than 1337 4ax0r worm writers who don't use real return addresses or phone numbers?
I know that the spammers who use the worm-enriched mailers aren't necessarily the worm writers, but they are paying someone to send the spam, so there's still a (worm) trail.
Yes, and programs compiled for 16-bit PDP-11 running on the VAX-11/780 in "compatibility mode" were faster than the same programs compiled for 32-bit VAX native mode running on the same VAX. It makes sense, they were doing pretty much the same stuff, and fetching half as much data. But of course, 11's had limited address space, and the VAX address space was relatively huge.
I just got to wondering... SCO is going after Linux because of its alleged source code borrowings. Might there be UNIX-derived code in Windows (or other non-UNIX OS's and perhaps even other non-OS software systems).
I am not fond of SCO's evil scheme, but I just wonder whether there is code overlap between UNIX and other software systems, and why it would have chosen the elusive Linux population as its target rather than a more well-delimited commercial product. (I'm guessing that most OS products might have the same sort of accidental overlap that Linux might have.)
Slashdot Mirror
The hacking is fun, a combo of real time control and game programming, and it's gratifying to be involved in software work that is more beneficial to humanity than the usual "moving bits from here to there."
that said, you note that we are talking about turning a digital master into a home recording. if you are going to look at that question, why not consider providing all the master information to the home user? i think you could provide a large amount of it if you were going to waste 30 megs on a 3-minute song (let's say you give the home user 8 channels plus the ability to tweak all the settings on a sound mixing board, with other signal processing also? With a "revert" button, of course. I think that would be a much nicer than 30 megs of bloated .wav. What, you say, most people would just make a mess. Well, we already have bass, treble, volume, and balance control. That's just a poor set of controls to do what we really want.
Is lossy compression really like 8-track tape? Well, they are both lossy. But besides being lossy, 8-track tape was read-only (practically speaking - I don't remember anyone recording 8-track tapes). It was terribly mechanical and prone to head misalignment in typical (in-car) use. Most importantly, you can't get an exact copy from an 8-track tape, like you can from any non-DRM digital medium. This, in particular, is an essential difference between tape (especially cheap tape) and a bag of bits.
You ask about what I meant by "always losing data. let's say that a master saved input from 32 microphones each sampling at 100khz, 128 bits per sample. 50 megabytes per second, 3000 per minute (if I multiplied correctly). A lot now, someday, not a lot. From that minute of music, we are choosing 10 megs today for our so-called "lossless" compression. Do we get a better representation of the signal by choosing a lossless signal or a lossy one, given the same amount of space? When I said "we are always losing data," I was suggesting that when you realize that you are always losing data (because the 30 meg .wav is not an accurate represesntation of the master), that you will get a better signal from 30 megs output from a good lossy codec than 30 megs output from a lossless codec.
i was familiar with standalone dired, not with the emacs mode. i su to root, cd to /tmp and start deleting files. disk-full error messages are streaming away, messing up the dired screen display. at some point, it must must have asked me, "are you sure," and i probably typed yes.
a minute or so later, it types starts complaining about missing a whole bunch of stuff in /bin. what had happened, is that emacs dired listed . and .. as files that i might want to delete, and i asked it to delete them (when the screen was askew from constant disk full system error messages). bsd dired did not have this feature that provided the opportunity to delete . and .., so when i asked to delete /tmp/.. , it went to / and started deleting merrily away, and died after it deleted /bin/rm, which it must have been using to do the actual deletions.
we didn't have the presence of mind to just mount the disk on another machine, i don't remember why, maybe just trauma, but in those days, most workstations had just one disk.
we looked at /bin and saw that we had /bin/sh and /bin/uudecode. (the files in /bin were stored in alphabetical order). /bin/ls was gone (ls before rm), but we got a directory listing with "echo *" which was a shell built-in. we used /bin/sh to type in a shell script with while and read and echo to create an ascii text file that was a uuencoded binary of cat, I think, so we could read from a 5 inch floppy or something.
we eventually brought the system back to life. it was not my finest hour.
The author of this article shows no understanding of signal processing or how music data is compressed, so his conclusions are silly. Comparing lossy music compression to 8-track tapes is silly.
He complains about lossy compression, but saving signal data (like photos or music) is always a lossy process, because there no exact digital representation of them. You decide to save a certain amount of data, let's say, 3 megabytes (or 30 megabytes) for 3 minutes of music, and then you decide what to put in those megabytes. You will always be able to get more/better data into the same space if you use signal processing compressors than if you just use uncompressed samples saved at some sampling rate and width per sample.
People who don't understand signal processing have a problem with the concept of "lossy." Signal processing engineers are not idiots. They don't design algorithms saying "I want to lose information and make a lower quality signal." They're just saying, "I want to save the data in this much space, which part of the data do I want to lose?" If you're saving recorded music, you are always losing data. The goal is to lose the least important part. The idea is slightly subtle, and it is apparently confusing to some people.
How important is it that they stuffed lots of people into two theaters for one day? Not to comment on whether or not I agree with the politics of his movie, but this lead paragraph reminds me that Moore is often inclined to twist and spin the truth to suit his point of view, which, at least for me, weakens his message.
- support for variable width fonts. this would require some finessing tabs, and perhaps an easy way to switch to a fixed width font. while you're at it, support unicode and other fat fonts.
- ability to search for text (with a regexp, of course) in the output window.
I think plan 9 has these, but I use unix/linux, and acme / wily don't cut it for me as handy *nix ui's. They seem wonderful in theory, but I could never get wily working on my *nix boxes in practice.Congress people want their cars fixed cheaply. Congress people do not hack their XBox.
prior art laundrygami
my laptop screen collects fingerprints, and i bet it's cheaper than this fancy robot.
Though the Honeywell 16 series was designed as an I/O processor for he internet, they were also ganged together (not quite beowulf) and used as timesharing machines. I hacked the 1648 for a while, i think it was two 516's (one for OS and one for as many user jobs would fit in 32 K), and a 316 for I/O.
With three nicely spaced holes, you could use it for bowling.
bwah bwah bwah imagine a beowulf cluster bwah bwah...
- it claims perl is the granddaddy of modern scripting languages. not true.
- it claims perl was critical in the initial construction of the Internet. not true.
- it discusses problems with the complexity of expressions, and then throws in regular expressions. expressions are not the same as regular expressions.
It's nice to know that folks are working on improving perl, but I found the article as confusing as typical perl code.I think your comment applies equally to this retensioning device as it would to a system that retuned with digital filters, but it doesn't address my question of whether you could just do it all digitally without retensioning.
why not just keep the strings at one tension and alter the tunings by processing the output wave forms? this would be simpler, and electric guitarists already run their signals through other effects boxes. (i'm not a guitarist or a signals engineer, i'm just curious.)
Encumbered? That's chutzpah. The famous Yiddish definition of chutzpah is when a man kills his parents and then throws himself at the mercy of the court because he is an orphan.
I was surprised to see no mention of Vint Cerf's InterPlaNetary Internet Project.
my boss changes color to display information at a glance.
yeah, and american strongman general mills manufactures count chocula, favorite breakfast treat of the chinese oppressor.
hey sco. go sue yourself.
note that the bible is full of gnurdly specifications if not actual tech docs, the earliest one perhaps, concerning the building of a boat. (scroll down to 6:14.)
I know that the spammers who use the worm-enriched mailers aren't necessarily the worm writers, but they are paying someone to send the spam, so there's still a (worm) trail.
Yes, and programs compiled for 16-bit PDP-11 running on the VAX-11/780 in "compatibility mode" were faster than the same programs compiled for 32-bit VAX native mode running on the same VAX. It makes sense, they were doing pretty much the same stuff, and fetching half as much data. But of course, 11's had limited address space, and the VAX address space was relatively huge.
I am not fond of SCO's evil scheme, but I just wonder whether there is code overlap between UNIX and other software systems, and why it would have chosen the elusive Linux population as its target rather than a more well-delimited commercial product. (I'm guessing that most OS products might have the same sort of accidental overlap that Linux might have.)