74min equal to 750MB??
Helge
When I have extracted the tracks from audio cds (using Nero) I have
noticed that the cds of 74min can turn out to be around 750MB
(Wave-files). How can this be?
I thought 74min was equal to 650MB.
Can I make a copy of a cd which Nero says is 74min and 750MB and use a
normal 74min/650MB disc?
Thanks,
Helge.
Bman
>noticed that the cds of 74min can turn out to be around 750MB
>(Wave-files). How can this be?
Simple. A .WAV file is just that - a file. It has headers, footers,
margin and tab settings, colour pallettes and the whole ball of wax.
It ought to be bigger than CD-DA tracks, which are not files and
contain none of the extra garbage that a file contains.
(Yes I was joking about the .WAV file components!)
CD-DA is not a file system and so has none of the extra bits that go
along with that, other than a TOC or index at the beginning.
That's where your discrepancy lies. 650MB is mode 1 file storage
capacity, and 74 minutes is CD-DA audio storage capacity. the two are
not equal.
Byron
Yusri Saad
problem...
You may wish to try.......
Helge wrote in message <35f03b76...@news.riksnett.no>...
>
>When I have extracted the tracks from audio cds (using Nero) I have
>noticed that the cds of 74min can turn out to be around 750MB
>(Wave-files). How can this be?
Sébastien Desmedt
used for error correction). But the .WAV (on your hard disk) format has.
This is why the files on the hard disk take more place than on the CD-Rom.
The error correction informations are copyed to your WAV files but, when
you copy it back to the CD, these informations are not transmitted to the
writer. The ECC (error correction codes) are generated by the writer
during the burning (or, sometimes, by your software) but the size of the
CD is calculated without these codes...
Yves Belle-Isle
>
> Well, the CD-DA format (on the CD) has no CRC (cyclic redundancy check,
> used for error correction).
In fact it doen't have EDC (Error detection code in form of a 32Bits
CRC)
and no ECC (Error Correction Code which is 276 bytes long)
>But the .WAV (on your hard disk) format has.
False it is a direct copy of the audio numeric data on the source CD and
as it as no EDC/ECC it is 2352 bytes of audio by sector while there is
only
2048 bytes by sector on a DATA mode 1 or Mode 2 Form 1 CD-ROM disk
> This is why the files on the hard disk take more place than on the CD-Rom.
No it's just because there is more DATA in a CD-DA sector than on a DATA
sector.
> The error correction informations are copyed to your WAV files but, when
No, because there are no EC information in a CD-DA file
> you copy it back to the CD, these informations are not transmitted to the
> writer.
When you write a CD-DA you write 2352 bytes by sector in place of 2048
for
a Data CD unless you do an uncooked DATA copy which is another story.
So 1X Data = 75 frame/second X 2048 bytes/frame = 150KB/sec
1X CD-DA = 75 frame/second X 2352 bytes/frame = 172KB/sec
> The ECC (error correction codes) are generated by the writer
> during the burning (or, sometimes, by your software)
False there is no ECC for a CD-DA disk those byte are used to store more
music samples in a sector
>but the size of the CD is calculated without these codes...
It's normal they are not there...
So 74 Min Audio = 74 min X 60 sec X 75 sectors X 2352 bytes =
783,216,000 bytes or 749.9 MB
A Mode 1 or Mode 2 Form 1 CD-ROM = 74 X 60 X 75 X 2048 bytes =
681,984,000 bytes or 650.4 MB
The difference 101,232,000 bytes or 96.5MB is the space used by
the 276 bytes/frame ECC + 4 bytes/frame EDC + 24 bytes Control =
304 bytes X 74 min X 60 sec X 75 sector = 101,232,000 byes
The control bytes contains:
For Data Mode 1: 12 Synchronisation bytes
4 header bytes
8 blank bytes
For Data Mode 2: 12 Synchronisation bytes
4 Header bytes
8 Subheader bytes
The 4 Header bytes contains the Logical Bloc Number and the
mode in which this frame (Sector) is written.
Cause the Header contains the LBN of the frame when it read
a DATA CD-ROM the reader can verify it is reading the frame
asked for. For CD-DA as there is no identication of the frame
in the frame, the reader can't be sure of which frame it
just read. That's one of the reason why so many cheap CD-ROM
drive are so bad at doing DAE and it's what Ripping program
call Jittle. It's because than every time the reader must
stop and restart while doing DAE, it must reposition itself
at the next frame to read, and if it position himself at
a frame too soon or too late, without jittle correction in
the ripper, you will have some frame duplicated or missing.
For complementary information take a look at the following page:
http://www.adaptec.com/support/faqs/cdcap.html
Yves
Cap-De-La-madeleine
Québec, Canada
Yves Belle-Isle
>
> a Data CD unless you do an uncooked DATA copy which is another story.
Difference between Cooked and Uncooked Read/Write
Note: Not all CD-ROM and CD-R/CD-RW drive can do all the cooked,
uncooked stuf, some can do only parts of what is possible.
That apply only to DATA CD-ROM not CD-DA CD cause those only
use uncooked Read and Write
Cooked read: The drive read the raw data (2352 bytes), extract the ECC
and EDC (280 bytes) and use those to valide and correct if possible,
the payload data (2048 bytes). Then pass to the calling program only
the correct payload data.
Uncooked read: The drive read the raw data (2352 bytes) and pass it,
as it without interpretation, to the calling program.
Cooked write: The drive receive from the calling program the payload
data (2048 bytes) and compute the ECC EDC bytes for it before
writing all those raw bytes to the CD-R or CD-RW.
Uncooked write: The drive receive from the calling program the raw
data (2352 bytes) and recompute only the EDC byte for it before
writing all those raw bytes to the CD-R or CD-RW.
It's because the drive always want to compute the EDC 4 bytes (CRC)
then you can't copy some games machines CD-ROM. It's because they
intentionnally write bad EDC values and check those on reading. Has
you can't write those bad EDC values you have to swap disk or use
modchip stuff.
Yves
Cap-De-La-madeleine
Québec, Canada
Decius Aiacus
Sébastien Desmedt wrote:
> Well, the CD-DA format (on the CD) has no CRC (cyclic redundancy check,
> used for error correction).
In fact it doen't have EDC (Error detection code in form of a 32Bits
CRC)
and no ECC (Error Correction Code which is 276 bytes long)
..................
Where did you find the above figures?
Yves Belle-Isle
If you would have read my orignal post entirely, you would have find
the following at the end of it:
For complementary information take a look at the following page:
http://www.adaptec.com/support/faqs/cdcap.html
And if you don't trust Adaptec you can try:
http://www.mscience.com/faq57.html
For a really technical explanation of the low level format of
CD take a look you can try:
http://resource.simplenet.com/primer/bits.htm
Yves
Cap-De-La-Madeleine
Québec, Canada
Decius Aiacus
Decius Aiacus wrote:
> Yves Belle-Isle wrote ...
> Sébastien Desmedt wrote:
> > Well, the CD-DA format (on the CD) has no CRC (cyclic redundancy check,
> > used for error correction).
> In fact it doen't have EDC (Error detection code in form of a 32Bits
> CRC) and no ECC (Error Correction Code which is 276 bytes
long).............
>
>If you would have read my orignal post entirely, you would have find
>the following at the end of it:
Unfortunately, you missed the "message" in my earlier post.
Which is that CD-DA has enough EDC/ECC codes to allow a 100% accurate
replication of ANY (non-defective/non-scratched/clean) audio CD!
And this by just using a Plextor as reader/recorder and following the proper
S/W-methodology.
The fact that data modes allows for an additional layer of EDC/ECC does not
mean that
the plain audio format can not be read correctly.
Yves Belle-Isle
The only error detection/correction than exist in a CD-DA is the low
level hardware CIRC in those 688-bit frame. Those garanties 1 bit
in error by million. As there are 176400 x 8 bytes / sec (1.3Mbits)
it's to say than the CIRC alone can have 1 bits in error by second.
By the way the plextor drive are the only one which does Perfect DAE
extraction. I built a special CD-R to test DAE which contains pseudo
CD-DA samples. In fact it contains tracks composed of know precomputed
sample, each one unique in the track so i can verify than what was
read is exactly what was written and if i read a bad value i can check
if it's a value valid at another point in the track. It would be the
case in case of jittle error or if in case of error the drive replace
the faulty sample by a good sample previously read. I tried at least
15, non plextor, IDE CD-ROM units and SCSI CD-R unit, and none can do
repeatable DAE extraction without error, the numbers of combined L+R
bad samples goes from 10 to more than 100,000 for a 256 sec track,
I.E. a track containing 11,289,600 of those 4 bytes L+R samples.
For sure doing DAE from a pressed CD not a CD-R would give better
result. But my conclusion is: As only plextor can do perfect DAE
from a CD-R, not a pressed CD, then why a consumer grade Audio CD
player, not designed to read CD-R, would do better DAE than a
modern CD-ROM, most even multiread so they can read CD-RW which
are way difficult to read than CD-R. My conclusion is than even
if i burn a perfectly read copy of a pressed CD on my Plextor drive,
when i will play it on an audio player it will read it wrong. My
listening test on many audio systems with lots of audio perfectionnist
tend to confirm my conclusion. So for me a CD-DA copy on a CD-R is
very usefull to keep the original in perfect condition, but i have
to accept a small audio quality degradation but it is normally way
less than if i copy the pressed CD on an Audio tape.
Yves
Cap-De-La-Madeleine
Quebec, Canada
Decius Aiacus
>The only error detection/correction than exist in a CD-DA is the low
>level hardware CIRC in those 688-bit frame. Those garanties 1 bit
>in error by million. As there are 176400 x 8 bytes / sec (1.3Mbits)
>it's to say than the CIRC alone can have 1 bits in error by second.
In real life Plextor claims an error rate of 1bit/10^9 when DAEing. (They
estimate a one thousand times decrease on this figure for data.) In
practice,
I have found these figures to be rather pessimistic.
I have replicated (by now) thousands of audio CDs, double checking the
recorded disk wrt the original for bit-by-bit accuracy. I have found only
TWO cases where I could not verify a 5 billion or so accurate bits on the
copy. The first was on a non-damaged original where I could read perfectly a
specific audio track only with DJ and "redundant overlapping audio" ON, when
DAEing at <4x. The second was when overburning using a Philips 6x media at
~76:50min. The last track (~25sec) contained ~500KB of errors, but still was
playing well on the UltraPlex (but not on some other players I tried).
>By the way the Plextor drive are the only one which does Perfect DAE
>extraction. I built a special CD-R to test DAE which contains pseudo
>CD-DA samples. In fact it contains tracks composed of know precomputed
>sample, each one unique in the track so i can verify than what was
>read is exactly what was written and if i read a bad value i can check
>if it's a value valid at another point in the track. It would be the
>case in case of jittle error or if in case of error the drive replace
>the faulty sample by a good sample previously read. I tried at least
>15, non plextor, IDE CD-ROM units and SCSI CD-R unit, and none can do
>repeatable DAE extraction without error, the numbers of combined L+R
>bad samples goes from 10 to more than 100,000 for a 256 sec track,
>I.E. a track containing 11,289,600 of those 4 bytes L+R samples.
There is actually a better (and simpler) way to test the recorded track wrt
the original WAV. Just use DOS: "fc /b". There is known that except a
1-2frame shifting, all bits are written correctly. I have posted here
several times a methodology for obtaining a 100% accurate audio/game copy.
>For sure doing DAE from a pressed CD not a CD-R would give better
>result.
Actually, I have found that the opposite is true! (At least in my case.)
I find more frequently errors on pressed than on recorded CDs. Of course,
this might be due to the fact that the latter are quite new and well treated
by me.
> But my conclusion is: As only plextor can do perfect DAE
>from a CD-R, not a pressed CD, ...
Panasonics are also able to DAE perfectly. Some other drives also exist.
Plextors just offer more options for controlling their speed and there is by
now a better S/W support for them. (And they are also able to read Karaoke+G
disks!)
>... then why a consumer grade Audio CD
>player, not designed to read CD-R, would do better DAE than a
>modern CD-ROM, most even multiread so they can read CD-RW which
>are way difficult to read than CD-R. My conclusion is than even
>if i burn a perfectly read copy of a pressed CD on my Plextor drive,
>when i will play it on an audio player it will read it wrong. My
>listening test on many audio systems with lots of audio perfectionnist
>tend to confirm my conclusion.
The ONLY way to tell if there is really a difference is to use the optical
output of a modern player and direct the signal to a soundcard that is able
to digitally transfer the bit stream onto HD.
If there is a difference, then this (by probability laws) will sound as
clicks-and-pops (or as a low amplitude "jitter"), not as an audible sound
degradation. I have never encountered this any of my personal copies. (Using
Mitsui gold 6x, of course.)
>So for me a CD-DA copy on a CD-R is
>very usefull to keep the original in perfect condition, but i have
>to accept a small audio quality degradation but it is normally way
>less than if i copy the pressed CD on an Audio tape.
Again I assure you that there is no such problem. As long as the copy does
not skip on the player (due to re-reads in case the layer1 ECC fails), then
you here what exactly the original would have to offer. Any "accidental"
errors might equally well have appeared on the original as well.
Regards, Decius
PS Can you e-mail me any information you might have available for the raw
sector encoding on audio CDs? (Layer1 EDC/ECC and the like.)
Grey
Decius Aiacus wrote in message <6sud75
>> But my conclusion is: As only plextor can do perfect DAE
>>from a CD-R, not a pressed CD, ...
>
>Panasonics are also able to DAE perfectly. Some other drives also exist.
Can you suggest Plextor or Panasonic models by type that should be
considered for purchase if I want DAE performed as best as possible?
Thanks.
Alex
with a question I am trying to solve but I can't.I am trying to get some
information about how to make a cd-text, you know, the one which shows the
name of the song and the album if it is fit in an appropiate system that
accepts that . The only information I have got comes from Sony but is
necessary to send to them the CD. Do you know something about this CD
system?
Thanks in advance
www.r...@goodnet.com
based in Phoenix, Arizona. WE ARE VERY SERIOUS ABOUT ACQUIRING THE VERY
BEST CD-ROM PROGRAMMERS USING THE VERY BEST VIDEO CODEC AROUND.
PERIOD. If you are the very best CD-ROM programmer, graphic artist or
video compressionist, please send an e-mail with your resume to:
big...@jhtproductions.com.
We are also looking to add to our website design team. We want only the
very best. No interns, no training.