I have one of the original Shigaclones and while I can offer no technical explanation the difference in the listening experience is dramatic.
Regards,
Dan
Yes indeed. You can actually change a lot of samples in a wave file and never hear the difference. To hear the difference would require some rather bad, continuous errors. That does happen, but it's very noticeable.
When listening to it thru an outboard DAC? It's dramatically different to what other transports?
Data CD's are not music CD's. You don't write wav files in the same format to a CD and have it play in a CD player. The entire music CD has its own format. This is why you can't drag and drop them like files onto your PC.
Like I would trust your word over the guys who have been developing software for over 10 years, and offer it for free? Get real. Usually you're a sound dude but right now you're sounding like a putz, mate. The EAC guys deserve some serious respect.
Ah but going up the range brings more improvement, not a revue but blatant advertising fro high end sh*te...
I am banned from the site for some reason, ML (Mr Pr*t) banned me for having sensible views and asking questions...
Look around you at all the digital data and how it has evolved, proof enough....
Untrue, whilst the data content is different the read write is exactly the same it is a series of bits read from a optical medium, same way that you can send differing data types over the internet or USB, the data content differs (WAV file or a JPG for example) but the low level communication is the same for all data, it is just a series of 0's and 1's transmitted (baseband Ethernet, broadband is more complex)
Scott showed no disrespect. He just pointed out (as many of us have found) that errors that require a re-read on a music CD are very very rare. Scott also knows rather more about signal integrity than even good SW devs.
Did you know music and data CD's are physically different, by just a little? It's perhaps unnecessary, but true. Someone else will have to answer that one... maybe for a different angle optimization?
Again, a data cd can infinitely re-read to get exact match. CD's are limited to the tolerable buffer time a consumer can stand between hitting play and waiting for music.
When reading data, or ripping CD's optical drives can burst read. This isn't an option when using a streaming transport due to noise and complexity of the buffer system that would be needed to sync on demand burst reads that would correct errors.
If you were to say ripping is bit perfect and the computer drive you used didn't matter, that would be mostly correct. (Unless it was one that scratched the disc because it can't handle burst ripping)
There's databases that compare rips of music CD's, and some drives are consistently off without the proper laser offset setting. That's why EAC has setup procedures, for example, as well as a database I believe for optimal drive settings.
Do properly operating transports sound different? I don't know, but they aren't bit-perfect.
Again, a data cd can infinitely re-read to get exact match. CD's are limited to the tolerable buffer time a consumer can stand between hitting play and waiting for music.
When reading data, or ripping CD's optical drives can burst read. This isn't an option when using a streaming transport due to noise and complexity of the buffer system that would be needed to sync on demand burst reads that would correct errors.
If you were to say ripping is bit perfect and the computer drive you used didn't matter, that would be mostly correct. (Unless it was one that scratched the disc because it can't handle burst ripping)
There's databases that compare rips of music CD's, and some drives are consistently off without the proper laser offset setting. That's why EAC has setup procedures, for example, as well as a database I believe for optimal drive settings.
Do properly operating transports sound different? I don't know, but they aren't bit-perfect.
Sorry Bill, but I think this thread has been hijacked by you guys that know everything else about everything, and they're trying to force themselves on this topic where they're wrong and don't have the experience with designing drives that go in transports. I assume they're right about countless other things, but on this subject all signs of expertise point to them being assumptively wrong.
If you mean facts vs beliefs that is consistent with many threads.
But if you step back. EAC cannot play CDs, what is can do is rescan sections of disk where there is an unrecoverable error due to damage (or the disk spinning too fast). So it can do a bit perfect rip on a CD that (due to damage) would have unrecoverable bit errors.
I have ripped at least 500 CDs over the years using EAC. Only two have had errors that exercised EAC. Both has been sliding around inside a car until scratched to buggery. One took nearly an hour to read. But that has nothing to do with audibility of transports when playing an undamaged disk.
But if you step back. EAC cannot play CDs, what is can do is rescan sections of disk where there is an unrecoverable error due to damage (or the disk spinning too fast). So it can do a bit perfect rip on a CD that (due to damage) would have unrecoverable bit errors.
I have ripped at least 500 CDs over the years using EAC. Only two have had errors that exercised EAC. Both has been sliding around inside a car until scratched to buggery. One took nearly an hour to read. But that has nothing to do with audibility of transports when playing an undamaged disk.
Executable software will fail with a single bit error in the wrong place; if that error is in one of the opcodes.
Checksums are exactly that - a way to verify the integrity of the file.
With software, if there is a checksum error, the data is re-read, or the packet is resent in the case of say, a download.
In fact music and data cds aren´t physically different. Same optical properties, same data rate, same EFM, same reed solomon and the same frame size and so on.
Differences start at the next level, where the meaning of the bits retrieved and organized is concerned. At that point additional error correction was implemented and the organization of data is very different.
Corrrect, that´s why i did emphasize that James A was talking about a system delivering analog audio output in realtime.
If no realtime action is required of course everything would be much easier when reproducing music some time later.
To be sure, one has to examine the specific devices in question. But as said before, generally error samples from a transport are really rare (means according to our experiments, 1 - 2 per hour, provided the disc wasn´t seriously damaged) and will therefore most likely not be the reason for audible differences.
People will then argue about which make of memory chip is best for storing music.marce said:
Oh dear, I see they are already arguing about which make of Ethernet cable is best for music. Only someone who knows absolutely nothing about computer networking (or hopes his customers/readers are similarly ignorant) could show any interest in this. It is even more silly than those who argue about USB cables.
I think this is one of those questions which if you need to ask it provides adequate proof that you would not understand or accept the answer. However, I will try: for a program to work it has to have millions of bits all correct. Change any of these and the most likely outcome is that the program will crash, either quickly or slowly. A much less likely outcome is that it will run but produce bad results. An even less likely outcome is that it will run and produce correct results. This is because a computer program is an example of an extremely highly-ordered system; almost any change is likely to lead to degradation. Hence software distribution relies on those bits being perfect, for almost every time on almost every sample of physical media. So yes, IT requires bit perfect copies. You can check this for yourself: write a simple program, debug it and get it to work OK; now randomly change one character in the source code - it probably won't even compile, and even if it does it may not work correctly. This is not the same scenario as corruption of binary code, but it is an analogue of it.leadbelly said:
The bare drive won't be bit perfect, which is why heavy error correction is used. The output from that is bit-perfect almost all of the time.Destroyer OS. said:
Marce is right, CD's are on their way out, kid's and young adults rarely buy them. Nowadays they prefer to download their favorite tracks, they rarely even buy a full album.
Whatever we might think of this, their buying power will dictate the markets future direction. I'm now being told that all physical based formats amount to nothing more than future landfill.
Whatever we might think of this, their buying power will dictate the markets future direction. I'm now being told that all physical based formats amount to nothing more than future landfill.
I.ve done over 800 and had a similar experience, possibly two that had bad sections that couldn't be read....
I've ripped about 1000 with no fails... CDs work very well I think! (I'm excluding the CD that was broken in half...)
I was not so lucky, had more failures than that. Some were damaged CDs, but others not. Still failed. I don't know why.
Here is an honest question for the guys who say that CD transports don't work right, or are not bit perfect. Why don't you test it to see for yourself? It isn't that difficult, just a bit time consuming. You may find that there is nothing to worry about, or you may find that your transport is NOT working properly. That would certainly be interesting and worthwhile.
I'm willing to help anyone who wants to test his CD transport. I can even provide test files, if you like. You will need some hardware and some free software.
I'm willing to help anyone who wants to test his CD transport. I can even provide test files, if you like. You will need some hardware and some free software.
- Status
- Not open for further replies.