Thorsten:
>This way we can use up all the old Ram Sticks and get the Reader to fill a local buffer (say 10 second read ahead) asyncronously with data, including multiple reads on errors.<
I know some designers who have done precisely this (including the multiple read technique), and their subjective assessment was that the biggest sonic benefits occur when the drive is powered off completely. Their conclusion was that the RAM buffer should be large enough to contain a complete song (and preferably the entire CD).
hth, jonathan carr
>This way we can use up all the old Ram Sticks and get the Reader to fill a local buffer (say 10 second read ahead) asyncronously with data, including multiple reads on errors.<
I know some designers who have done precisely this (including the multiple read technique), and their subjective assessment was that the biggest sonic benefits occur when the drive is powered off completely. Their conclusion was that the RAM buffer should be large enough to contain a complete song (and preferably the entire CD).
hth, jonathan carr
Banned
Joined 2002
Konnichiwa Carr San,
Well, once we get 1024 speed CD Drives that should only a few seconds to load... For now, while I appreciate the issues, I suspect a sufficiently seperate supply will go much of the way.
In most ways, binary data is binary data. as long as all circuiuts are seperate, coomon and differntial mode whatever clocks out the data from the buffer should dominate. Of course, shared supplies are BAD NEWS.
Sayonara
jcarr said:
Well, once we get 1024 speed CD Drives that should only a few seconds to load... For now, while I appreciate the issues, I suspect a sufficiently seperate supply will go much of the way.
In most ways, binary data is binary data. as long as all circuiuts are seperate, coomon and differntial mode whatever clocks out the data from the buffer should dominate. Of course, shared supplies are BAD NEWS.
Sayonara
This is a interesting project!
I sow few time ago all this corean pages but I don't understand these language
In this case I'm very motivated to perform something here and I hope will make a working project!
Question:
- The final quality of the drive is not depending on the global quality of the CD-ROM drive?
- Who can we make a distinction between a good and a by drive?
It is better to use the digital out from the drive or the data flow from the ATA/IDE interface ?
Alex
I sow few time ago all this corean pages but I don't understand these language
In this case I'm very motivated to perform something here and I hope will make a working project!
Question:
- The final quality of the drive is not depending on the global quality of the CD-ROM drive?
- Who can we make a distinction between a good and a by drive?
It is better to use the digital out from the drive or the data flow from the ATA/IDE interface ?
Alex
Q: what about all these new copy protection systems that wont let you play a audio cd in a cdrom?
The TOC or whatever it is is messed up, making the cdrom go que about the cd?
you can probably solve it by making new firmware for the cdrom but that might be some troubles involved in that
sorry, dont want to shoot down the projekt, it is very interesting , I have been thinking about it myself.
/rickard
The TOC or whatever it is is messed up, making the cdrom go que about the cd?
you can probably solve it by making new firmware for the cdrom but that might be some troubles involved in that
sorry, dont want to shoot down the projekt, it is very interesting , I have been thinking about it myself.
/rickard
I'm also very interested in doing something similar (building a transport for use with a separate DAC). I'm fairly skilled in programming and very skilled in hardware design, so I would gladly help where I can.
Firstly I think we should all decide what controller/processor and language etc we want to use. What we need to know for this decision is of course what features we would like to add and how wide the bus to and from the CDROM needs to be.
So far I have gathered that we want:
- remote control
- about 5 buttons
- interface to a computer (?) (RS232? USB?)
Does anyone know how wide the bus should be? I'm guessing 16bits, but haven't had time to read up on the subject.
I think if we could get this information together we can start hardcore teamwork and produce a really good transport. Please post any relevant info and controller etc suggestions.
DJ
Firstly I think we should all decide what controller/processor and language etc we want to use. What we need to know for this decision is of course what features we would like to add and how wide the bus to and from the CDROM needs to be.
So far I have gathered that we want:
- remote control
- about 5 buttons
- interface to a computer (?) (RS232? USB?)
Does anyone know how wide the bus should be? I'm guessing 16bits, but haven't had time to read up on the subject.
I think if we could get this information together we can start hardcore teamwork and produce a really good transport. Please post any relevant info and controller etc suggestions.
DJ
It is certainly a very good idea to get the audio data through the ATA interface, store it in a gigabyte of RAM and play it from there.
But: I think this is somewhat beyond the possibilities of the "normal" DIYer.
Let's have some short calculations:
There is about 700 megabytes of data on a CD, and it plays 74 minutes. So we have to deal with about 700x1024=716800 kilobytes. This is close to 12000 kilobytes a minute or 200 kilobytes a second.
If we want to use a fast drive - modern ones are up to 56x speed, let's assume we will get 50 times the normal speed in reality (wich is of course a little optimistic, I know) - we will have to read and store 200x50=10000 kilobytes or 10 megabytes of data in a second. This is nearly impossible with the operating speed of a microcontroller, but would allow us to read a CD in less then 2 minutes - very interesting, no doubt.
Even if we could find a microcontroller capable of handling this enormous data stream, there are some other technical problems to solve: for example the interface of a gigabyte of PC RAM to the controller. Modern memory architectures are rather complex and need a lot of timing and refreshing issues to be covered - not that easy.
I think if that's the way to go one should use another strategy: simply buy a cheap modern PC mainboard, attach a flash memory card as a boot device, plug a gig of memory on it, connect the CD drive, install Linux and write such an application. This is certainly much easier (and a lot cheaper) then building a special hardware solution.
The idea just to have a certain amount of memory to buffer some seconds of data is another issue - and I think this is not necessary a drive issue. That kind of memory based reclocking is something that could be done in a DAC.
Okay, we would lose the advantages the high speeds of computer CD drives.
Personally, I think we should stick to something that has a chance of being realized: a "normal" drive, perhaps with some some good ideas concerning data transmission to the converter: My vote would go for I2S via LVDS.
LVDS is a very interesting high speed data transmission system by National Semiconductor, which operates fully balanced with a differential voltage of only 400 millivolts. Very fast, very reliable and the chips are availeable.
But: I think this is somewhat beyond the possibilities of the "normal" DIYer.
Let's have some short calculations:
There is about 700 megabytes of data on a CD, and it plays 74 minutes. So we have to deal with about 700x1024=716800 kilobytes. This is close to 12000 kilobytes a minute or 200 kilobytes a second.
If we want to use a fast drive - modern ones are up to 56x speed, let's assume we will get 50 times the normal speed in reality (wich is of course a little optimistic, I know) - we will have to read and store 200x50=10000 kilobytes or 10 megabytes of data in a second. This is nearly impossible with the operating speed of a microcontroller, but would allow us to read a CD in less then 2 minutes - very interesting, no doubt.
Even if we could find a microcontroller capable of handling this enormous data stream, there are some other technical problems to solve: for example the interface of a gigabyte of PC RAM to the controller. Modern memory architectures are rather complex and need a lot of timing and refreshing issues to be covered - not that easy.
I think if that's the way to go one should use another strategy: simply buy a cheap modern PC mainboard, attach a flash memory card as a boot device, plug a gig of memory on it, connect the CD drive, install Linux and write such an application. This is certainly much easier (and a lot cheaper) then building a special hardware solution.
The idea just to have a certain amount of memory to buffer some seconds of data is another issue - and I think this is not necessary a drive issue. That kind of memory based reclocking is something that could be done in a DAC.
Okay, we would lose the advantages the high speeds of computer CD drives.
Personally, I think we should stick to something that has a chance of being realized: a "normal" drive, perhaps with some some good ideas concerning data transmission to the converter: My vote would go for I2S via LVDS.
LVDS is a very interesting high speed data transmission system by National Semiconductor, which operates fully balanced with a differential voltage of only 400 millivolts. Very fast, very reliable and the chips are availeable.
I disagree to some extent Holger.
Firstly, if you want to dump the whole CD in memory, you're half way to building an MP3-player which is not what we had in mind.
Buffering the music in memory is also not quite as hard as you make it out to be. I have not done it myself, but have seen quite a few people connect PC memory to microcontrollers in recent years. Successfully I might add.
The easiest way to realise such a buffer (in my opinion) would probably be to use something like Dallas/Maxim's TINI system as a base. The controllers for such systems runs at around 75MHz (The same as early Pentium 1's) and can handle 16Mb of memory. The chip is based on 8051 architecture, so many of us should be able to program the code for it in a variety of languages (I know Dallas' also works with Java). The fact that it has virtually all the power of a P1 with the added bonus that we wont be running massive OSes like Windows means you actually have MORE "music-play-ability" than a P1.
The beauty is you can get a couple of them FREE on sample from Maxim/Dallas (www.maxim-ic.com), so your argument that it would be cheaper to go the PC way is obviously untrue.
The only tricky part would be the PCB layout and manufacture, but if this project works out I will gladly make and sell a few PCBs to all interested.
Finally, a friend of mine who works part-time in the IT industry suggested we rather use older CDROMs such as a Creative 2x or something. The reason being the over the years the actual quality of CDROMs deteriorated to make them cheaper. Don't bite my head off for this suggestion...
Firstly, if you want to dump the whole CD in memory, you're half way to building an MP3-player which is not what we had in mind.
Buffering the music in memory is also not quite as hard as you make it out to be. I have not done it myself, but have seen quite a few people connect PC memory to microcontrollers in recent years. Successfully I might add.
The easiest way to realise such a buffer (in my opinion) would probably be to use something like Dallas/Maxim's TINI system as a base. The controllers for such systems runs at around 75MHz (The same as early Pentium 1's) and can handle 16Mb of memory. The chip is based on 8051 architecture, so many of us should be able to program the code for it in a variety of languages (I know Dallas' also works with Java). The fact that it has virtually all the power of a P1 with the added bonus that we wont be running massive OSes like Windows means you actually have MORE "music-play-ability" than a P1.
The beauty is you can get a couple of them FREE on sample from Maxim/Dallas (www.maxim-ic.com), so your argument that it would be cheaper to go the PC way is obviously untrue.
The only tricky part would be the PCB layout and manufacture, but if this project works out I will gladly make and sell a few PCBs to all interested.
Finally, a friend of mine who works part-time in the IT industry suggested we rather use older CDROMs such as a Creative 2x or something. The reason being the over the years the actual quality of CDROMs deteriorated to make them cheaper. Don't bite my head off for this suggestion...
Just a CD Drive
So a small summary.
Frankly what I see from the posts is that most people want a cheap replacement of the Philips CD-PRO.
The CD-Drive should consist of the following:
based on an IDE CD-ROM player.
controlled by a "cheap" microcontroller.
display (VCD or LCD).
5 buttons (or more).
digital out.
have it's own power supply.
remote controlled (RC5).
The "firmware" in the microcontroller should be upgradable "in-circuit" via a serial link (cheap and easy to program).
This way it's possible to add features to the CD-DRIVE in the future. I think it's a good idea to focus on the basic functionality in the software first (play - stop - rew - fwd - eject) and some basic information on the display.
Most new CD-ROM drives have "digital out" so we could use that one for start and maybe develop direct data extraction in a later stadium.
MGB
So a small summary.
Frankly what I see from the posts is that most people want a cheap replacement of the Philips CD-PRO.
The CD-Drive should consist of the following:
based on an IDE CD-ROM player.
controlled by a "cheap" microcontroller.
display (VCD or LCD).
5 buttons (or more).
digital out.
have it's own power supply.
remote controlled (RC5).
The "firmware" in the microcontroller should be upgradable "in-circuit" via a serial link (cheap and easy to program).
This way it's possible to add features to the CD-DRIVE in the future. I think it's a good idea to focus on the basic functionality in the software first (play - stop - rew - fwd - eject) and some basic information on the display.
Most new CD-ROM drives have "digital out" so we could use that one for start and maybe develop direct data extraction in a later stadium.
MGB
Thank you for the summary, mgb.
I think you did exactly hit the point.
I think you did exactly hit the point.
Absolutely. Today's microcontrollers are mostly programmed via a so-called "ISP" (In System Programmeable)-port, wich should be implemented on the application board. The programming tool for this ist a super simple circuit with a single TTL chip and some passive components and plugs to the printer port of any PC. The programming software is of course freeware. So everybody intersted in this project should be able to to the controller programming on his own and keep on track with the upgrades.
that gives us Atmel or Microchip microcontrollers to choose from?
flash-rom, cheap, easily accessible, fairly fast (all MCUs are that today ) , lots of nice peripherials (depending on model) , cheap or
free development software (preferably freeware)
and not to forget, single chip solutions (simpler PCB and construction)
/rickard
flash-rom, cheap, easily accessible, fairly fast (all MCUs are that today ) , lots of nice peripherials (depending on model) , cheap or
free development software (preferably freeware)
and not to forget, single chip solutions (simpler PCB and construction)
/rickard
Why not give these guys some new challenges...
http://www.diyaudio.com/forums/showthread.php?postid=169707#post169707
(CD-Rom & CD-Pro controller was earlier discussed here)
Arne K
http://www.diyaudio.com/forums/showthread.php?postid=169707#post169707
(CD-Rom & CD-Pro controller was earlier discussed here)
Arne K
Cobra2 said:
I think Dale and Craig would do it if there is enough demand. I remember when we started posting about them doing such a project, but it kind of fizzled out.
I think they have a few more volume control boards to finish, but when thats done a CD-ROM kit would be a DIY lovers dream come true. I'm sure it would take off.
-Vinnie
Well I guess everyone can choose what he/she wants to do, but I'm not the type of DIYer that builds from a kit. The fun for me is in the designing AND the building, so whatever you guys do, I'll be doing the thing from scratch and anyone interested can pitch in with info/help/advice etc.
Just a note to Rickard, we're definitely not limited to just Atmel and Microchip. Like I said already, the Dallas controllers are still a possibility and there are a few others (Motorola etc) that should also not be discounted yet. As soon as I've finished gathering all of everyone's requirements, I will start looking into which controllers fit the bill (and our pockets!). Of course anyone else is also welcome to check it out.
So here's what I have so far:
- 5 or more control buttons
- remote control
- buffer memory (8 or 16Mb should be MORE than enough)
- digital out (FireWire? SPDIF)
- LCD display
Anything else???
I await your replies...
DJ
Just a note to Rickard, we're definitely not limited to just Atmel and Microchip. Like I said already, the Dallas controllers are still a possibility and there are a few others (Motorola etc) that should also not be discounted yet. As soon as I've finished gathering all of everyone's requirements, I will start looking into which controllers fit the bill (and our pockets!). Of course anyone else is also welcome to check it out.
So here's what I have so far:
- 5 or more control buttons
- remote control
- buffer memory (8 or 16Mb should be MORE than enough)
- digital out (FireWire? SPDIF)
- LCD display
Anything else???
I await your replies...
DJ
Glad someone knew what diy means.
Still think a serial link for upgrading the firmware would be great.
Also, If not to hard to implement some flash module where you can store CDDB information regarding the disc playing. This info could be uploaded through the serial port. I believe the information is matched with the TOC of the cd. This is a feature I've never seen on any stand-alone player.
MGB
Still think a serial link for upgrading the firmware would be great.
Also, If not to hard to implement some flash module where you can store CDDB information regarding the disc playing. This info could be uploaded through the serial port. I believe the information is matched with the TOC of the cd. This is a feature I've never seen on any stand-alone player.
MGB
Konnichiwa,
Sounds spot on. One thing remains. Do we extract the data to be buffered and reclocked via S/P DIF or via the IDE/ATA interface? I am in favour of the latter.
If we just add a S/P DIF RAM buffer we can make that a simple stand alone device.
And a controller with all the requirements listed above is available as Kit from www.diyzone.net so all we would need to get this working is a group buy which includes someone who writes and reads chinese in the group.
Sayonara
DJ said:
Sounds spot on. One thing remains. Do we extract the data to be buffered and reclocked via S/P DIF or via the IDE/ATA interface? I am in favour of the latter.
If we just add a S/P DIF RAM buffer we can make that a simple stand alone device.
And a controller with all the requirements listed above is available as Kit from www.diyzone.net so all we would need to get this working is a group buy which includes someone who writes and reads chinese in the group.
Sayonara