593 karma · joined March 5, 2012
I've made a few simple microcontrollers and microsequencers in Minecraft (as 'micro' as you can get with a 1M feature-size) and I've often fantasized about bigger projects, but it's only been fantasy.
Still, it lends itself reasonably well to old NMOS-style layouts...
It wasn't done this way then and isn't done this way now not because it's impossible (or even that hard), it's because it usually doesn't make sense compared to the alternatives. It's slow and burns a comparatively large amount of resources.
That said, the project is interesting precisely for the reasons that it renders these lessons concrete, and apparently was fun to implement.
...now back to my Minecraft RISC-V....
Air assist, yes (to clear smoke and particles from the beam and protect the focus lens from soot), but that's just an air pump, not a gas supply.
Some home-built tubes do use a gas supply, but virtually no one builds their own CO2 tube to use in a laser cutter when better tubes are available on eBay for $100.
The more interesting aspect, verified by testing, is that it does work.
In my own testing, SCL to SDA will not work on the T2X, T3X, T4X, T60, X2X, X3X, X4X, or X60. It does work on the T61/X61 and T400/500.
PROT to GND works on all of the above. I also tested it on an X230 (works), but I didn't check SCL to SDA on that machine.
PROT is not the WP pin. They're different. Go read the spec sheets.
The original hack as discovered was PROT to GND, not SCL to SDA. My only speculation was as to why the hack as reposted changed over time.
But I was more interested in the end-to-end test, as I expected others reading would also be:
SDL to SDA (the usual instructions given elsewhere) only works on some models.
PROT to GND appears to work on all. In my collection of ~ 30 machines, it works on all the models SCL to SDA does, as well as all the models SCL to SDA does not.
PROT to GND was the original hack as discovered around the time of the T20.
No, I don't know a trick for new machines, and am unlikely to look for one. Modern Thinkpads aren't machines I'm very interested in.
My motivation here is the same as most people buying old Thinkpads off eBay-- getting past the SVP on machines with a dead CMOS battery. I don't give a fig about any data on the hard drive :-)
The published papers tend to be by the same people making the supertweeters
Beating and intermodulation distortion are entirely different things. They look similar on an oscilloscope, but they're not and they don't sound the same.
>Instruments are not limited to 20-20kHz. They can have overtones well above this range.
Correct. You can't hear the overtones beyond the upper portion of the hearing range (many people believe you can).
>In a real listening environment (i.e. live performance) these overtones have a chance to interact with one another in the air.
In reality they do not unless you're driving the air so hard the trough rarification is approaching hard vacuum. (That's not actually impossible. It's how ultrasonic audio 'beaming' devices work). Some performances are powerful enough to get close, eg, if you're sitting six feet from the pipe organ.
Once you're driving air so hard it becomes nonlinear, thus introducing intermodulation distortion in the air, that distortion produces actual audible-range distortion products. And because the distortion you're hearing is in the audible range, a recording will sample and reproduce it accurately.
You're hearing the audible _result_ of IMD, you're not somehow listening to the distortion curve itself.
> It is possible that these overtones may beat with one another
You're continuing to confuse beats and IMD, but here you're talking about beat frequencies, so Yes. But beat frequencies are a sort of auditory illusion. If one of the frequencies that would produce a beat is inaudible--- there's no beat. Easy to test, go try it.
> and cause inter-modulation products in the audible range.
IMD is not a beat. Inaudible ultrasonics will produce audible artifacts when the underlying reproduction system is nonlinear (another way of saying 'there's intermodulation distortion'). However, that's a playback artifact. If the IMD products were audible in the original signal, audible range sampling would reproduce them.
If it wasn't audible in the original performance, it should not be part of the recording, and it should not be part of the playback.
The article is still correct, just like it always was.
Ironically, most of your analysis is also correct. Somewhere in your understanding though, you're leaping sideways to an incorrect conclusion.
>The basic problem: the quieter a sound or detail gets, the fewer bits of resolution are used to represent it.
So far so good, but you're about to go wrong again once you start thinking in terms of stairsteps and boxes and looking instead of hearing.
Back to the bits.
What lower amplitude (and fewer used bits) means is that the sound, as represented, is not as far above the noise floor as a full-amplitude sound. The digital noise floor is completely analogous to, eg, the noise floor of analog tape. If you use a dithered digital representation, you get something that behaves exactly as analog does. You hear and perceive both the same way.
>In 16-bit recording, there simply aren't enough bits to represent very low level details without distorting them with a subtle but audible crunchy digital halo of quantisation noise.
On an audio tape, the magnetic grains are just too large to represent very low level details without distorting them with a subtle but audible crunchy halo of analogue distortion and hiss.
In a 24 bit recording, the noise you mention is still there! It's just shifted down [theoretically] 8 bits or -48dB. That's the only difference. The noise floor is lower.
[In reality, 24 bit isn't. Most recordings don't even hit a full 16 bits, and no recordings, unless they're mathematically rendered, can get deeper than about 21 bits. There is no such thing as a 24-bit audio ADC/DAC that delivers 24 bits. The very best available today are about 21 bits of signal + 3 bits of noise.]
So the difference in playback between 16 bits and 24 bits is about 5 actual bits. If you're complaining about soft sounds in a 16-bit recording 'not having enough detail' because they're down at, say, 3 bits of resolution, are you saying it's all fixed by using 8? Aren't 8 bits woefully too few for any kind of quality sound?
(I hope at this point, you realize you're barking up an incorrect tree)
If you're following me so far, we can continue, but I expect even this much is going to require more conversation.
If this is worth using (and it's the first thing in several years that made me sit up and say 'ooOOoo') it won't get lost. There will be a way for the world to use it.
(Almost everything else currently using stems is mogg-based given the per-unit royalties for MP4 software support)
oops.
http://wiki.xiph.org/Videos/A_Digital_Media_Primer_For_Geeks...
Only a few things have changed since then. I've done some more work within Cinelerra (I wrote a new resampler and a new color grading filter for it this time around). I'm also using a pair of matched suspension microphones (AT853a Unipoints) instead of the Crown boundary piezeos, which I've decided just aren't suited to anything I do.
Cinelerra is not for the faint of heart, and I don't casually recommend it. It is very powerful, rather unfriendly, and picky about the formats it uses. However, it will do things none of the other FOSS editors can.
It was easier to use a real example than try to draw something by hand that was close to correct :-)
In short, I found no FOSS video editor that did what I needed reliably out of the box. Given that problem, Cinelerra at least came close, the code was readable, and the design sound. Its biggest problem is that its file loaders/exporters are all old and bitrotting so they have become unreliable and crash-prone. For my stuff, I use raw video and so don't hit those problems.
In the process of making Episode 2, I wrote a new compositor resampler and a new color grading filter for Cinelerra (named Blue Banana). These should be appearing officially in the next major release. I hope to have some more file loader work done by then too :-)