Xéna a écrit:Je me suis amusé à extraire le même morceau d'un CD original et de sa copie. Les 2 fichiers sont identiques au bit près.
Avec quel outil ?
voila par exemple ce qu'on trouve dans la doc de Audiograbber :
The difference between audio CD's and normal data CD's.
(Or why is it so hard to copy a track from a music CD?)
A CD-ROM is divided into sectors of 2352 bytes. Data CD's use 2048 of these bytes to store the data file. The other bytes are start / stop information and information of the sector's number. This makes it easy for a computer's CD-ROM device to find the right sector. An audio CD on the other hand uses all of the 2352 bytes to store audio information. This makes it hard for the CD-ROM reader to find exactly where the track starts. All bytes are coming in one long sequence. When the CD drive starts reading it usually has no problem delivering the right data but most CD drives have problems with starting on the correct byte (sample).
A sector (it is called a frame on audio CD's) on an audio CD, as stated earlier, is 2352 bytes. There are 75 frames per second which gives 2352 * 75 bytes per second of music. (This can also be calculated by 2 (stereo) * 2 (16 bits) * 44100 Hz per second). Philips "Red Book" standard specifies that a CD player should be able to position its head on the right frame but not where on the frame.
Since a computer program has to read a little piece of the track, write it to the hard disk, read another piece etc. there will be problems all the time. The program solves this problem by reading a little bit more data than is written and then compares the end of the previous reading with the beginning of the present reading and in that way can synchronize the readings. (This is called overlapping, synchronization or jitter correction).
Audiograbber can use two different ways of reading the audio, MSCDEX or ASPI, of which ASPI is the preferred one. ASPI can be used in a kind of multi threaded mode which means that the program can ask for data and get a notification back when the data has arrived. This way the program can do other things while waiting for data and it is often possible to not use any synchronization at all, the data can be copied correctly in a burst copy mode. If the drive spins faster then the computer can handle the data there will be "possible speed problems".
In MSCDEX mode you can select how many frames of audio should be read in every chunk and with how many frames overlapping. The program does not always get enough memory for all the frames it wants which means that it sometimes has to use a smaller audio buffer. (Under MSCDEX the program uses the low DOS memory to buffer data from the CD drive and depending on what other device drivers and programs want memory from that area, it can differ a bit from time to time or computer to computer)
The more sectors that are used for overlapping, the slower the CD driver will read. When windows 95's protected mode CD-ROM driver is used, the data from the CD drive is always cached and it seems to make the synchronization unnecessary. If a real mode driver is used for the CD drive and if the data is not cached the synchronization is necessary.
Whether the CD drive reads the audio perfectly can be tested by:
· Compare two files
· Calculate checksum
Compare two files
This function is found under the file menu.
The purpose of this function is to test if your CD player reads digital audio perfectly.
When digital audio is read from the CD there is a problem with the beginning of the frames. That is because there is no proper beginning and end of the frames, rather a long consecutive sentence of bytes. This means that if a track is read twice from the CD, the files should most likely be almost exactly the same. Usually, it is only some 1/1000 of a second difference, so it does not matter much.
The disadvantage is that the DOS command fc /b track1.wav track2.wav can not be used to test that the files really are equal. The Compare Two Files function does a comparison in the same way but takes into consideration that the tracks may start a little bit differently. This function also skips the first 44 bytes because they are not part of the track, they contain file size and file format information.
The offset tells how many bytes (not samples, a sample is 4 bytes) the beginnings of the tracks differ from each other. The comparison is halted as soon as a difference is detected. If the track differs, it tells at which position. You can open the file in a program like Cool Edit and see how they differ. Remember that the hexadecimal value Audiograbber gives you should be subtracted by 44 and then divided by 4 to get the exact sample.
Another test function is the checksum function of Audiograbber.
This function is found under the file menu.
Some CD players that actually can read digital audio do not necessarily read 100% correctly. The resultant files are then not exact copies of the originals. This can also happen if the CD is scratched, has fingerprints etc. It is hard to tell if a track is read perfectly only by listening to it. Checksums are therefor a good way to test if the CD player read 100% correctly. When a track is copied from a CD disc, Audiograbber automatically calculates a checksum. By reading the same track on two different CD players the checksums can be compared. If they are the same then the tracks are also the same and the reading is perfect.
But hey, readings do not usually start on exactly the same byte, so how can a checksum be calculated then? Yeah, a presumption for this is that the track begins and ends with silence. The checksum will then be calculated on only that part of the track that is over a value of 127.
(A sample from the CD can be between -32768 to +32767 (16 bits). -32768 means that the speaker's membrane is pulled back as much as possible, +32767 that it is pushed forward to maximum position and 0 that it is in its middle position. The more the membrane is moving back and forth the louder the speaker is playing. Samples in the interval -127 to +127 are interpreted as silence in Audiograbber. When a checksum is calculated, Audiograbber finds the first sample outside this interval. Then it finds where the file goes outside the interval for the last time and after that it starts to calculate the checksum. It does not matter if there is a bit of silence in the middle of the track, that part will also be included in the checksum.)
NOTE! If there is not enough silence (one frame = 2352 bytes) in either the beginning or the end of the track an X is added to the checksum. This indicates that other readings from the CD may give other checksums even if they are read in the same way. The checksum can not be used if it contains an X.
By comparing checksums from tracks you have grabbed with your own CD with already known and confirmed correct checksums you can test if the CD reads the way it should. There are some correct checksums on http://www.audiograbber.com-us.net/checksums.html
that you can compare with if you are lucky to have some of the CD's listed. Understand that you must have a copy of the exact same CD, it is not enough to have the same song.
You can report your own checksums on http://www.audiograbber.com-us.net/checksums.html
. Those tracks should then have been read at least twice on a CD player that you are sure reads digital audio correctly. Report checksums from track 1,3 and 5. When you only want the checksum and not the entire track the function test comes in handy and you don't have to save the track on the hard disk.
Compare two files is another function that controls the CD's audio reading. If two checksums are not the same the compare two files function can see where the files are different. Checksums can also be calculated on tracks that have been read by other programs.