The crowd noise betwixt songs can be contained in a pregap, so that it is only ever heard when listening to the album straight-through (instead of in shuffle or track-program mode).
---
Another fun feature of audio CDs is indexes.
A disc can have 99 tracks, and each track can have some pregap (including track 1, as the article discusses). And each of these 99 tracks can be further subdivided with 99 index markers.
This gives a CD the theoretical ability to have 9,801 selectable audio segments.
Although realistically, I've only owned a couple of CD players that even displayed index numbers and exactly one CD player (a Carver TL-3300) that allowed a person to seek to a given index number within a track.
(And I've only known one CD to actually make use of indexes in any useful manner, which was a sound effects CD from the early 1980s that had a lot more than 99 sounds on it -- all organized by tracks, and sub-organized by index marks. I just can't think of the name right now.)
I have a classical CD from the 80's with index marks for different movements within within the individual compositions represented by a handful of tracks. My understanding is that DG was the only publisher routinely using them. That required some manual intervention to convert the indices to separate tracks. Sony was pretty good about providing index nav. on their full size stereo players. At least until their perpetually cruddy remotes eventually failed.
It's things like this that make me wish that we'd landed on on a good, popular way to store albums (with metadata!) instead of individual tracks -- or to at least reassemble individual tracks' files properly into whole albums without glitches and weirdness. (FLAC/cue can do some of this, but hardware player support is nearly nonexistant.)
I've been told that this is a stupid thing to want, and I want it anyway.
I'm old enough to remember listening to albums the whole way through by default since anything else would take extra steps, and perhaps fortunate-enough to have generally preferred listening to albums where that is a thing that is also worth doing intentionally.
(And yet, I am young enough to still be bitter about Lars killing Napster. My dissatisfaction is multifaceted.)
But the albums I like to listen to as albums will remain cohesive albums for an eternity.
Lots of stuff from Roger Waters is cohesive in that way, which is perhaps something a person might expect me to say.
But also lots of stuff from Maynard James Keenan, Trent Reznor, and even Marilyn Manson is also this way, which is perhaps less expected.
(And sure, I can rip an album as an album and convert that to a singular MP3 that I can play as an album almost anywhere, and it needs to be a single file since MP3s can't be perfectly concatenated. But then, I can't easily skip around on that singular album when it behooves me to do so.
I could do both things when it was still in CD format.)
Her recordings are excellent. They generally sound simply fantastic. When turned up on the big stereo, they tickle every auditory input I have -- including the usually-strictly-tactile ones.
I've heard that her brother, who is probably (and perhaps obviously) her biggest fan, generally has a huge part in producing and mixing her music. It is apparent that they work well together.
Anyhow, thanks. That album is on the list for the next time the neighbors have left for the weekend.
I've never looked inside a CUE file, but it's just text and I don't think it supports meta data, right?
We need like a new CUE file to go with the FLAC, right?
The audio should be able to be FLAC. But it should also be able to be anything else, like Vorbis or MP3 or AAC or IDK. It needs to be able to be played continuously without aberration (which can't actually be done with a group of MP3 streams).
The audio needs to be able to be seekable, like a CD is also seekable. By track. By index. (With pregaps, where appropriate -- because CDs also have pregaps.)
Other potential metadata must be able to include whatever subcodes are involved in things like CD+G[0] and HDCD and CD Text, since all of those are supersets of the regular datastream and playback is compatible with any CD player.
And it needs to be a singular container file because...well, that's just easier to keep track of as the years go by and data migrates.
Only then, will we have the beginning of a valid archive format for audio CDs as they actually still exist on [some] store shelves today.
(Some stuff can be optional, just as lots of things are optional inside of an MKV container for a film.)
[0]: Almost nobody ever used this outside of the 1990s karaoke world, but Information Society's self-titled album includes an illustrated sequence, with lyrics, that is completely implemented in CD+G and that runs for the entire length of the album. And I should be able to render that locally here in 2024 from a container on my pocket supercomputer instead of watching a bad rip from a Sega Genesis: https://www.youtube.com/watch?v=b89sSa8QlLg
Audio codecs: use a single stream of whatever codec you'd like. FLAC/Vorbis/MP3/AAC/Opus/etc. can all go into Matroska.
Seekable: Use chapters for tracks, and nested chapters for indices. Matroska documentation even gives an example of using ChapterPhysicalEquiv 20 for CD tracks and ChapterPhysicalEquiv 10 for CD indices.
Other metadata can be muxed into the stream as well.
Lyrics can be included as text in metadata (lyric tag) or as a subtitle stream.
Liner note graphics (and basically anything else) can be included as embedded files.
Music videos can be video streams in the Matroska file.
I mean: As mentioned, these have almost never been usable with real CD players in the wild. Maybe not much is lost there. (But the format must still accept these things, and allow them to be usable! An archival format must respect all aspects of the item being archived, including those that are unpopular or disused. I am willing to die on this hill.)
What of things like CD+G? Here in 2024, they're very simple graphics using 35+-year-old tech, and they should be archived neatly, precisely, and without interpretation, to be rendered client-side at a later point. I think I've mentioned it, but we literally have pocket supercomputers in common use today. If we can make the complexities of MAME work for the past couple of decades, and do it with direct ROM dumps, we can do this for CD+G.
But the CD+G must be rendered synchronously with CD audio data on playback. This applies whether it is my Goldilocks example of an Information Society album, or whether it is a CD+G karaoke disk with Garbage's I'm only happy when it rains (and twelve other crowd pleasers from that month of 1995).
How will that work with MKA?
And how will pregaps work?
(Maybe MKA isn't an ideal container if it does not already include avenues that lead to this kind of functionality in ways that are compatible with the original article.)
There were also a ton of Audio CDs that were not CD+G but had a data track with the music video etc on them.
I worked on a horrible one for Sony, one of those ones with all the anti-rip protection on it, where I was tasked to build a binary blob for a web site that detected if the specific audio CD was in your drive and let you into the web site. What were those things called, ActiveX?
I think you're referring to ActiveX, yes. It's the only thing I can think of where "web" stuff and "hardware" stuff commingled back then in a semi-transparent way.
And famously, as you surely know yourself, Sony once published some rootkitted audio CDs: https://en.wikipedia.org/wiki/List_of_compact_discs_sold_wit...
Anyway, I'll just assume that you aren't the rootkit guy -- or even if you are, that your heart is in the right place.
---
And yes, CD+G is is important. As are the mixed-mode releases with video. All things CD audio are important if we are to talk about an ideal archival (and playback!) format for audio CDs, and archiving an audio CD is not always quite as simple as ripping a folder of FLACs -- there's a ton of diversity here that FLAC (and cue) can't accurately embody.
We're fortunate that we still have so many CDs right now, and that they're still being sold today. This will change. (It must change. It can't not change.)
The good folks working on the Domesday Duplicator have a relatively uphill battle for the often-older (and often rotting) LaserDisc media that they're working on tools to properly preserve.
It would be good to get ahead of the curve and get something with a practical workflow working sooner instead of later.
There are a number of requests out there to extend the chd format and fix a few things. They are currently tracking some of this info in XML files (called hash files). They would be down with more accurate information though. So you would need a proposal that adds more accurate information and gives them something to work with. More like getting all the info that something like the redump project tracks in there would make them very happy.
There is a separate project that some other emus use libchdr which is a soft fork of MAME. I think they are trying to track closely to what the MAME group is doing but let other emus use it.
Which I get on the one hand, but it's a bummer that in all these cases (CD, DVD, Blu-Ray) the metadata for the larger structure of the production got inextricably tied to the specific physical media implementing it, such that the only real way to preserve that data was to rip a full disc copy.
For me, Sony remotes were made of the same stuff as early Nokia phones - indestructible! Surprised to hear someone thought they were cruddy.
I wish I could remember the name of the textbook because I really liked a lot of the baroque music on the CDs and can't remember who they were by or the titles of the songs...
There were a dozen regular tracks. A bunch of empty ones. And the final track over about a dozen tracks of varying length with no gap. Used all 99 tracks.
I could only pull it off with this CD burning software that didn’t have a UI. It took a text file as input at the command line. But it could do everything from almost every color of spec (Red Book, Blue Book, etc) for CDs.
"WTF? The time counter keeps going forward, and then sometimes it goes backwards! And using the track seek buttons completely eliminates some parts that I can hear if I don't touch anything!
It's a whole different song entirely when you program tracks 39, 40, and 52 in a loop, and IDFK what it is with this Index number that only always showed "1" before.
Oh wait. Srsly? From tracks 71-93, it's using the index to count beats...and the track number to count measures? No, that can't be it. Except...."
https://en.wikipedia.org/wiki/Broken_(Nine_Inch_Nails_EP)#Pa...
Amarok (1990) by Mike Oldfield is a single hourlong track with 53 index marks.
https://en.wikipedia.org/wiki/Amarok_(Mike_Oldfield_album)#T...
(Both have their merits, but I unfortunately have neither at hand. And I only have one of these 2 albums. And one of those albums is the original Broken, which only has 6+2 tracks across two discs instead of 99 tracks on one disc.
And how do the 91 silent tracks on a more-common release of Broken affect things compared to the 26 musical tracks that the original 6+2+18 track-count ensemble may entail, in terms of inter-song delay or any other such thing on a real multi-disc changer?
I know TMBG fairly well, and NIN very well, and I enjoy the fuck out of gear, but I have so many questions.)
(I vaguely jest above, but Spotify only shows me 18 tracks on Apollo 18. And only one of them is Fingertips. Am I looking at this wrong?)
I could not tell you what brand the all-in-one turntable/radio/tape deck/cd player I had at the time was. There was a big tray with room for five CDs and I have absolutely no memory of how much noise it made when switching from one disc to another, and every physical object involved in this affair is long gone in a hurricane.
I suspect both CDs should be easy to find used copies of, if you have the appropriate hardware and want to experience the tension of not knowing if the next song you hear is going to be Trent bitching, a brief moment of silence, a Fingertip, or whatever else you put in the player. Given my tastes at the time this would have probably been Skinny Puppy, Ozric Tentacles, and Björk, but do whatever feels like the most interesting possible choice; I have a disc lying around now that’s nothing but forty iterations of Satie’s Vexations and that would have certainly been a prime choice for this little game.
In my location, it shows as a single track that is 4:33.
Looking Fantomas up on Wikipedia makes it sound like they'd go pretty well with "twenty tracks that sound like the choruses of twenty different songs" and "ninety-something 1s blank tracks plus a few industrial songs", though.
On your pregap + 99 indexes remark, the "pregap" is the space between index 00 and 01 which continues on up to index 99. Players seek to index 01 as the start point of the track. There is no separate pregap designation. I've paid special attention to this because it is a difficult problem to solve as many discs have space between tracks stored in index 00-01 but rarely is there anything audible in there after the first track. The only example I have of this is a specialty music sample disc, Rarefaction's A Poke In The Ear With A Sharp Stick, that has over 500 samples on the disc accessed by track + index positions.
As a sidebar based on the later comments in the thread, I've made it a habit to rip and store every audio CD as BIN/CUE+TOC using cdrdao. This allows me to go back and re-process discs I may have missed something on. But that is imprecise even because it usually breaks bluebook discs with multiple sessions to store data due to absolute LBA addressing. Also the ways different CD/DVD drives handle reading data between index 00-01 on track 1 is maddening. Some will read it, some will error, and the worst is those that output fake blank data.
E.g. the Japanese version of Flying Lotus' album "Until The Quiet Comes" has a pregap of 5 seconds before the 19th track, to separate it from the rest of the album, as it's a Japanese-exclusive bonus track.
https://github.com/superg/redumper/
Caveat: It is mostly intended for use with the low-level features of Plextor drives, so CD support on other drives is relatively limited; in particular it doesn't have any overlapping read paranoia-style features. The recommendation is to dump twice to confirm; it's running straight through without seeking so that's usually still quite fast.
Cuesheet looks like:
TRACK 04 AUDIO
INDEX 00 00:00:00
INDEX 01 07:34:43
That messed with a tool that only anticipated one index in track 1 for detecting hidden pregap audio, cuesheet is like:
TRACK 01 AUDIO
INDEX 00 00:00:00
INDEX 01 00:00:37
INDEX 02 00:11:40
INDEX 03 00:37:33
...My (early) Philips CD player dealt with it fine, but since then it's been a bit of a problem...
Each track is designed to segue into any other so the album is different every time you play it.
I love these hidden tracks to death, especially the two hidden pregap tracks on Ash's first album, but they caused me unending pain and suffering.
Not only are they an absolute nightmare to rip, often with more than one song per track (so the WAVs have to be edited), the names of the songs are often totally unknown, even to the record labels. What do you even number the things in the metadata?
Added to that, you nearly always didn't even know they were there, so the negative numbered tracks would fail to get ripped and all the other ones in between or at the end would get ripped in weird ways and confuse all the data folk.
https://www.discogs.com/release/984235-Ash-1977
"Help, computer."
When I looked it up online I found out it was called “The Real Song for the Deaf”. It was literally a song for deaf people, the idea was that if they turned it up enough they’d be able to hear the vibrations forming a song.
For those interested to listen via a more accessible method: https://www.youtube.com/watch?v=XEU01LrnWng
If a CD is properly following the Red Book standard, index 0 will point to a 2 second pre-gap of silentce and index 1 will point to the actual start of audio of the track (additional indices are allowed, but not common). The purpose of the pregap is to make life easier for less sophisticated players that aren't able to seek to a precise frame on the disc. They just have to be able to hit a 150 frame region. However, just because the standard says the pregap is supposed to be 2 seconds and silent doesn't mean it actually has to be. Players generally don't care and by the time the format was popular, even inexpensive players could seek precisely. This allows you to stick audio data before a track that will be skipped by the player when it's trying to seek to that track. If you stick it before track 01, it will be skipped even when just playing the disc through unless you rewind.
Some players permitted you to skip back from 1.1 to 1.0 to hear the lead-in as a hidden pseudo-track. Typically this was only possible with hardware index nav. buttons rather than the track nav. buttons, further obfuscating the presence of the hidden track.
The other means of "hiding" tracks is to have a bunch of short silent tracks until you get to track 99 (inconvenient to reach on a player without numeric track entry) or to have a long section of silence starting on the last track from index 1.
Holding the previous track button would "rewind" playback and get you into the pregap on all the CD players I remember using, but these would have been late 80s models onwards.
Was it limited to something negligible like a couple of seconds?
Or could you store a whole five-minute recording in there or something?
Edit: Son of a *, I've had a copy of Sister Machine Gun's Burn for almost 30 years and never knew there was a hidden track!
> These albums all had a pregap of either 32 or 33 “frames,” with a frame representing a length of about 1/75th of a second, per Hydrogen Audio’s Wiki.
> To offer a small correction to the original question now that we know we’re talking about 74 frames per second rather than 60 or 100
It's needlessly confusing and undermines my confidence of the entire article.
(Sometimes songs can also be hidden in tracks at the end of the CD like 99, but that feels less mysterious.)
Other CDs really experimented with the shuffle feature. They Might Be Giants’ Apollo 18 had a bunch of very short tracks that would usually play between songs when shuffle was used.
It was funny at first, but when every other CD I bought had one, it became tacky.
I think it was nine inch nails' Broken EP that had the hidden tracks on 98/99 rather than after a long silence, but I could be wrong.
The regular-sized CD looked about identical to the 99-track version, but had only 6 tracks.
(It was expensive to do this, and was never intended for long-term production. Later versions were generally as you describe.)
My copy in the UK at the time didn’t have the individual tracks. Just one track.
The negatives between songs were also pretty cool sometimes, Mediocre Generica by Leftover Crack makes very good use of them. Listening to it over streaming or even mp3s ruins the effect, unless someone captured the entire album as one file.
I wouldn't call it an “early” album but I found one of these (untitled 18-second intro) on AFI - DECEMBERUNDERGROUND: https://i.imgur.com/XAsFMSR.png
Some others I've run across in my CD collection include…
— on Jonathan Katz - Caffeinated https://i.imgur.com/4ghQadv.jpeg
— the track "Every Time Is The Last Time" on Bloc Party's Silent Alarm https://i.imgur.com/knhbZhA.png
— a kid606 remix hidden in the first track pregap of The Locust's eponymous https://i.imgur.com/sXVFrQI.jpeg
— the "Theme of Coon" (aka Riki) on the third disc of the SaGa Frontier soundtrack https://i.imgur.com/CqTTqpV.png
> The negatives between songs were also pretty cool sometimes
And one of these, the interlude at the end of “High Roller” on TCM's Vegas which is part of the pregap for “Comin' Back” https://i.imgur.com/G5PSCy3.jpeg
I think it was answer that and stay fashionable. We all stopped listening to them when black sails came out, so if im right about it being AFI, it was one of the first 3 albums, or the all hallows EP.
Those names are a rabbit hole event horizon. Album released 9/11, working title of Shoot The Kids At School was rej by label. Follow up was F WTC. Band lives in C-Squat...
Add in MusicBrainz Picard and Navidrome and you have a really nice solution.
I'd first heard of this for a Monty Python record (wikipedia notes this is in fact the most famous use case) but checked to see if people went for >2 grooves, and seemingly they did. I expect the casting for the pressing was horrendously expensive, which is why it didn't happen an awful lot.
I suppose both mediums shared the less-well-hidden feature where a long silence separated the penultimate from the ultimate track.
A needle creates the groove(s), replete with bumps for sound, in a not-quite-set (slightly soft) master disc - and I _speculate_ those follow a specific path defined by the mastering tool.
In comparison, playback just drops the needle in the track, and it necessarily follows the extant spiral form.
Making the master of a multi-groove record I'm assuming would require recalibration of the groove-defining mechanism (doubtless carefully designed for conventional layout), once for each of the grooves you want to make, ensuring they each stay within the boundaries defined by the previous grooves.
https://www.discogs.com/release/373044-Arcturus-La-Masquerad...
Also on the topic of trying to push the compact disc to its limits a Grindcore group who had a bonus track where "All efforts were made to exceed typical limitations of 16 bit linear digital technology compression, limiting, and equalization curves have been created to deliver maximum gain structure"
https://www.discogs.com/release/4305023-Exit-13-Ethos-Musick
I had a period of bad luck in my youth where I believed all these new enhanced CD's and shaped CD's were damaging the tracking of the lens on my CD player so I gave Exit-13 a swerve and started to listen to safer music ;)
The one exception is a field for "extensions", which should have some bits for 'compatible' extensions (ie. there will be extra data ignored by readers which don't understand them), and other bits for 'incompatible' extensions (ie. you have put a DVD into a CD player).
The album the parent mentions is Reise, Reise, which is travel themed (in a broad sense of the word), the cover being styled after a black box (being bright orange of course). The flight recording in the pregap literally comes from a black box of a plane crash so that fits.
It's mostly just scrambled alarms and some Japanese yelling. Without the context it's pretty hard to understand what you're listening to.
https://en.wikipedia.org/wiki/Unusual_types_of_gramophone_re...
https://www.discogs.com/release/369188-Korn-Follow-The-Leade...
I have no idea how they got a patent for such a thing and, even worse, anyone ever did it on actual commercial discs.
Especially bad since most Audio CD players are opaque hardware without update-able firmware.
Sent from my Discman
Instead, engineers and product managers, slow roll quirkiness on social media.
That's why the most robust CD image format is the BIN/CUE format. The BIN file contains all the sectors the drive allows us to read, the CUE file contains the disc metadata as interpreted for us by the drive firmware.
There are some drives which support extra "raw read" commands, but they're incredibly rare and consequently in great demand by CD preservation projects like redump.org.
Some people have used the contents of BIN/CUE data to reconstruct what should actually be on the disk, but that's not quite the same thing. Here's a great explanation of the CD structure in all its complexity:
https://github.com/higan-emu/emulation-articles/tree/master/...
We do not currently have a widely supported CD standard for storing data from a CD that can properly hold all data. Aaru [0] is close, but still has to output back to other formats like BIN/CUE to use the contents of the disc.
If you want to look at the structure of a whole audio CD, then one way is to rip it with a decent tool (perhaps cdrdao or EAC) and generate a bin/cue file pair as an output.
All you need is the unmolested data from that disc. The data is arranged on a singular spiral groove starting from the center and slowly winding its way towards the outside.
The data is completely linear: It begins at the beginning, and continues to the very end without interruption. This is all akin to (although opposite of) how a single-track vinyl record is physically laid out. The entire CD -- whatever it contains -- is just a continuous string of pits and lands.
And to observe that string as it appears on a real disc, all you need to get started is a regular old-school CD player and some appropriate data acquisition gear, and maybe an oscilloscope to help figure out what you're looking at.
The optics and basic motor controls are already solved problems, and it doesn't even have to be particularly fast data acquisition gear by today's standards to record what is happening.
I believe I've seen there is work being done to attempt this on CDs but it would have still been in the exploratory phases and not yet ready to start archiving with. It might seem like overkill to do this to something meant to be digitally addressed but I've experienced enough quirks with discs and drives when ripping that I would 100% be willing to switch over to a known complete capture system to not have to worry about it anymore. Post process decoding also allows for re-decoding data later if better methods are found.
And at the risk of taking us well beyond the rainbow books, I'll just leave this here: https://www.psxdev.net/forum/viewtopic.php?f=70&t=1266
There cannot not be this layer.
(And with a sufficiently-old-school CD player, it is probably not even challenging to get to it. The less-integrated the parts are, the better.)
Aside: is your username inspired by Secure Socket Layer or Solid State Logic?
The difference between a pit and a land is an optical phase change. The pits and lands vary in length, and there are 9 valid variations in their lengths. This combined phase/temporal situation eventually (thanks, science folks from 1970-something!) turns into a serial binary electrical signal inside of a CD player.
This binary electrical signal can be recorded.
Recorded with what, you asked?
CDs have a lot more going on than just audio data: Remember, there's forward error correction at play and (by spec, IIRC) a player is supposed to be able to completely recover data even if there is a gap of 1mm due to a scratch or other interruption. (There's also room for tricks like CD+G to live in the background, and certainly what may seem like an inordinate amount of data used just for clocking: CDs are CLV, so playing them happens at a continuously-varying rotational speed in a tightly closed loop because buffer RAM was expensive to buy, and expensive to manage, and tight speed control was cheaper to implement. Remember, this was a finished digital product that was released in 1981.)
I find old references[0] that suggest that the raw data rate of a CD (it does not matter what kind) is 4.3218 Mbps.
So, to posit some example hardware: With careful loops and decent wiring, accurately capturing this seems like it would be well within the purvey of an RP2040's PIO's DMA modes to get that data into RAM, and also well within one of its 133MHz 32-bit ARM core's ability to package up and deliver that data over USB 2 to a host machine that can store it for later analysis -- plus or minus a transistor or two, or maybe a pullup resistor in just the right spot.
(But that's just my opinion as a home hacker who has dabbled in RP2040 PIO assembler, and who is at or a bit beyond their knowledge of compact discs. I may wake up tomorrow and decide that the above is all bullshit and wish I could erase all of it. If in doubt, Phillips datasheets for CD player chipsets from the first half of the 1980s can probably help a lot more than I can.)
---
As to the username: It's old. It predates Secure Socket Layer, but it's way newer than Solid State Logic. I was just a young kid with a new modem when I dialed into a Telegard BBS and started to sign up for an account, and got stuck at the prompt to enter a "Handle". I didn't know what a handle was in this new-to-me context.
The sysop saw that I was stuck and dragged me into chat, as good sysops (hi Shawn!) tended to do upon seeing such a thing. We chatted for a bit, and I wasn't feeling creative, so he suggested that maybe I could look around for inspiration since most people used a made-up handle on his particular BBS.
I found a 5.25" floppy disk on the desk that I'd borrowed from the local public library. It was labeled "Selective Shareware Library, Volume 3." (It was also almost certainly infected with the Stoned virus[1]).
Anyhow, that was sufficiently inspiring, so ssl-3 it was.
---
Floppies (most of them, anyway) have fixed track widths, and these tracks are arranged cylindrically, and these cylinders align with the steps of the stepper motor that is used to actuate the head assembly.
It's relatively easy, with the right ratio betwixt step advancement and track width, to get the head moving properly on a new implementation of a floppy controller. Want to read track 1? Step to the head N times to reach track 1 from wherever it started, and read it. Next, want to read track 33? Step the head N times to track 33, and read that.
But tracking the spiral groove of a CD is a very different problem to solve. Steps tend to lose their meaning. Instead of electromagnetic steps, it involves 3 different laser beams: Two to continuously keep the head centered where it needs to be on the ever-changing groove using a servo feedback loop, and a third to read the data from the pits and lands from the middle of that groove.
Is it do-able? Sure! People with far less advanced tech than we on HN might have laying around did it 40+ years ago.
It's just a very different nut to crack than reading a floppy is, even if the mechanical and optical bits are recycled.
(And that's just head positioning. The pits and lands still needs to be read, and those reflect back from the disc as optical phase shifts, not as changes in magnetic polarity and/or amplitude.)
It's impractical because the resolution required to retrieve the data "flatbed scanner style" is comically high, perhaps 50k dpi, far beyond the capability of any commercial unit and well into scanning microscope territory. Sure, from my understanding, it looks technically possible. But it would be a very significant and costly project just to assemble the image in the first place. Even if you had that, the resulting file would be hilariously huge (something like 122GB), extremely difficult to work with, and you would be starting from scratch implementing some kind of visual pathfinding helical decoder to painstakingly unravel the linear coil of data the scan just sort of blatted into two dimensions.
It's a cool idea. But it's comically, exponentially harder than just using the equipment as intended to just read the laser returns off the disk directly, into a far, far more easily dealt with format.
I'm adding that CD scan to my list of things I'd like to do if I ever get really rich.
