h a l f b a k e r yOutside the bag the box came in.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
One problem with anything like a CD jukebox is that no matter how big a unit one gets, one will outgrow it. And adding a second unit won't solve the problem (unless it's large enough to replace the first unit while accommodating more disks)
I would thus suggest a few notions:
(1) A unit which
can add multiple "track" sections, allowing for nearly unlimitted expansion in any one lineal direction. This would have the disadvantages of [1] requiring the 'trolley' to have a self-contained motor, operating like an electric train; [2] becoming slower and slower to retrieve disks as they got further and further away from the player; [3] requiring large amounts of space in one lineal direction; [4] a potential for jams as the trolley goes between sections [though with good engineering this could probably be avoided]. This notion, however, could have a major cost advantage over other methods of expansion, or could be used to cheaply make other methods more effective.
(2) Adding an 'elevator' to move the trolley to one of several levels, each of which could allow expansion via (1). This would improve storage density to a two-dimensional proposition.
(3) Using two player mechanisms, so that one disk could be playing while the next disk was being shuttled into position. This is already baked, but it could mitigate the slowness of (1).
(4) Having a "next disk" holder next to the player; while a disk was playing, the shuttle could retrieve the next disk from the rack and put it in the "next disk" spot. When the current disk finishes, the disk in this spot could quickly be moved to the player. If the player had a small readahead buffer, the new disk could be in play by the time that buffer was empty.
(5) Have multiple 'jukeboxes' with a linked control system and daisy-chained audio, to allow a single playlist to span collections (if player #2 disk #5 track #7 is supposed to start after player #1, disk #2, track #9, the second player could pre-load the disk and wait for a signal from player #1 before starting to play it).
(6) To go with the Sharper Image motorized jewel-box rack, a player which knows which jewel box the person removed and which can automatically start the disk in question. [note: this last technology could work also with a hard-drive based MP3 player].
Bakeded.
http://www.netcomuk...~wwl/cdjukebox.html
Mike's Electric Stuff. A cool site... [StarChaser, Jan 25 2002, last modified Oct 04 2004]
Sony's version of (5)
http://www.sel.sony...hangers/index.shtml
Only lets you daisy chain two players, though. [krelnik, Oct 04 2004]
[link]
|
| |
I like the idea on principle. [supercat] has certainly given due thought to many of the engineering aspects of the problem. I wonder, though, what the user interface would look like on an indefinitely expandable jukebox? Your CPU and interface software would need to support selection from an arbitrarily large collection. |
|
| |
Wait, I have an idea. Since this machine is sectional, have an independent CPU in each section, with its own interface panel. To select track T on disc D in section S, a user would walk to section S, and then key in T and D at the keypad there. The CPU will then send a series of messages over a token ring type network that connects the CPUs from all the sections. |
|
| |
Each CPU maintains its own queue of messages from other sections and from the player(s). That way each CPU knows how many song requests are in the queue, and also which, if any, belong to that section. No addressing data is stored in the queue. Only push (from CPU) and pop (from player) events are stored. |
|
| |
When A CPU recieves a pop event, the leading song request is removed from the queue and all other requests advance by one. If the CPU owns the song request that was just popped, it generates a stream of beacon messages to the player. The player then moves itself toward the beacon source until it comes to rest in the correct section. The CPU detects the player's presence and stops sending beacon messages. The player requests the disc and track information from the CPU, and then plays the reqested song. |
|
| |
Each section of the jukebox would have standard mechanical and logical interfaces to its neighbors. Adding a new section would be completely transparent to all but the nearest neighbor on each side. |
|
| |
Now we just need 3 corner sections to allow the straight-line jukebox to wrap around the perimeter of an arbitrarily-sized room. |
|
| |
Sorry for the lengthy post. But at least it is all on topic. |
|
| |
I've seen data systems like this, but not home stereo systems. As [PeterSealy] says, it would be very expensive. |
|
| |
The data systems work by cataloging every disc as it's stored. Since the player and the transport systems are separate devices, a CD can be played while another is retrieved. The form factor is usually a tower. |
|
| |
Rather than pick songs by disc/track as [BigBrother] suggests, the UI would probably allow the user to view a list of CDs then tracks and/or an alphabetical list of song titles. Note that this works (and has been baked) for DVDs and video tapes as well. |
|
| |
With hard disk space at, what 5 bucks a gig and dropping like a stone, wouldn't it be easier to simply have a pc or mac download all your cds when entered into the player, and store them like that? PC interface with remote control and a video driver to blow the menu onto the tv, sit on the couch click click, done. Infinitley upgradeable,500 cds would fit into a space the size of a regular cd player. |
|
| |
gus: Yeah, hard drive-based systems are becoming more and more practical, I'll grant that. At 20kbytes/second (160kbps) a gig is good for a thousand minutes. One part of me says that that's $5 practical for any big collection, no matter how huge. But the other part thinks there's something more 'real' about playing the actual disk, somehow. |
|
| |
Still, do you like my idea #6? |
|
| |
Number (5) has been baked by Sony for some time. I understand the newer ones that support what they call "Disk Explorer" (on screen directory display) even unify the on-screen display so you see a single list. Not sure if it supports doing programmed play as you describe. I'll dig up a link. |
|
| |