Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When I was first learning Linux many years ago a friend and I got intoxicated and catted /dev/hda into /dev/dsp. It was all basically static with sometimes very structured patterns that we would try to guess as to what filetype was producing them. He had download and forgotten about a long uncompressed audio recording of a piano performance on his drive that suddenly started breaking through the static in chunks of varying length. We came to the conclusion that this was probably just what the kernel source sounded like.


mplayer -demuxer rawaudio -rawaudio rate=48000 -format s16le -af volume=-20 /dev/sda

Warning, headphone users: may hurt your ears. Trust me on the volume lowering.

With 16 bit samples and (default) two channels, you can recognizeably hear small integer values in your left ear. :)


I remember when I discovered that while in engineering school. I would try to pipe all kinds of files to see which ones had interesting acoustic signatures. I remember .iso files to be particularly interesting.


for i in $(seq 1 10); do seq -120 1 120; seq 120 1 -120; done | aplay

It's for you.


Good skills.

It has never occurred to me to do that but it is actually quite an obvious thing to do when you "know" that everything is a file.

Any idea what the visual equivalent would be?


If you've got a framebuffer console, I think you can cat to /dev/fb ... Although pixels are less friendly than audio, it's kind of helpful for identifying patterns if you preprocess so everything is shades of one color, or a byte -> color map anyway.


Plan9's /dev/draw.


ffmpeg can point directly to the webcam under /dev/.


> Any idea what the visual equivalent would be?

Perhaps:

head -c800 /dev/urandom > /dev/tty

Or:

mplayer -demuxer rawvideo -rawvideo w=80:h=60 /dev/urandom


> mplayer -demuxer rawvideo -rawvideo w=80:h=60 /dev/urandom

Change that to w=720 h=576 (for pal countries) and you can relive the glory days of analog TV static. Except not - mey memory seems to tell me it's more colourful. I guess it's to do with the limited chroma resolution in pal?


As far as I understand/remember it:

Analog color television color information is sent "out of band" from the point of view of black-and-white television (as a sideband frequency, with neat analog trickery to cancel out its effect on main signal). Color TV is backwards compatible. It's unlikely that random input happens to look like meaningful properly encoded color information, so television static is largely black and white.


You can reduce the saturation as desired (0.6 below):

mplayer -vf eq2=1:1:0:0.6 -demuxer rawvideo -rawvideo pal /dev/urandom




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: