I'd argue that the apps you say don't use cores could, but the users hardly need a mac pro for those apps regardless.
Look at some of Apple's own programs, such as the consumer apps. Even those that should use 4 and even 8 cores don't. Look to iTunes, for example. Two cores. Why? No good reason at all. Just lazyness on the part of Apple.
There are plenty of other prgogams in that same situation. They could throw out more threads, but they don't. Performance suffers.
But, more cores do benefit you if you do several tasks at once, even now.
People right here have been calling for 4 core iMacs and portables, so it would be nice if all of those programs that would benefit from the use of more cores would do so.
Well, I know from my own experience that it's not just magically add threads to your program and voila! you have a multithreaded app. There are things that scale linearly with the number of cores that you have, and a lot of other things that do not. Even the ones that scale well are usually restricted by the memory bus or the I/O.
You say about iTunes... well... why would you need more than 2 threads in the usual work for iTunes? I don't see the point. You won't be listening two or more tracks at the same time, right? (And I'm sure that if that was/is possible in iTunes, you will get two different threads to play each one a track) Where you could "easily" have some multithreading is in the ripping or conversion process, there you can usually fire two or more threads to convert each one a file. But not much people have more than 1 cd drive, and you can only read single-threaded the cd... in any case, it is somewhat feasible to have that, and for instance, Max does it and very very well, specially the file conversion process, there you can easily get a big boost if you enable more than one thread. The ripping sees a boost, but it's not near to linear at all.
Multithreading IS the future, I'm convinced of that, but in many cases, if not the majority, the big advantage for the consumer will be being able to use 3 or 4 apps, "heavy" apps, without problems, at the same time. And that you can have it right now, even with single-threaded apps, and not-really-state-of-the-art schedulers. Those apps that could have taken advantage of multiple processors have already taken it, maybe not 100%, but near. And they will continue to improve, that's for sure, because that's what the market demands, but there is stuff that you just can't convert to multithread.
I fear that we will get another Mhz myth, but this time with multithreads. They are tools, not the silver bullet to solve all of our needs. At some point people wil realize that, and the industry will have to move to the next big thing.
Well, I know from my own experience that it's not just magically add threads to your program and voila! you have a multithreaded app. There are things that scale linearly with the number of cores that you have, and a lot of other things that do not. Even the ones that scale well are usually restricted by the memory bus or the I/O.
You say about iTunes... well... why would you need more than 2 threads in the usual work for iTunes? I don't see the point. You won't be listening two or more tracks at the same time, right? (And I'm sure that if that was/is possible in iTunes, you will get two different threads to play each one a track) Where you could "easily" have some multithreading is in the ripping or conversion process, there you can usually fire two or more threads to convert each one a file. But not much people have more than 1 cd drive, and you can only read single-threaded the cd... in any case, it is somewhat feasible to have that, and for instance, Max does it and very very well, specially the file conversion process, there you can easily get a big boost if you enable more than one thread. The ripping sees a boost, but it's not near to linear at all.
Multithreading IS the future, I'm convinced of that, but in many cases, if not the majority, the big advantage for the consumer will be being able to use 3 or 4 apps, "heavy" apps, without problems, at the same time. And that you can have it right now, even with single-threaded apps, and not-really-state-of-the-art schedulers. Those apps that could have taken advantage of multiple processors have already taken it, maybe not 100%, but near. And they will continue to improve, that's for sure, because that's what the market demands, but there is stuff that you just can't convert to multithread.
I fear that we will get another Mhz myth, but this time with multithreads. They are tools, not the silver bullet to solve all of our needs. At some point people wil realize that, and the industry will have to move to the next big thing.
In any cases, interesting times :-)
Regards,
Rodrigo Gómez
I'm not talking about playing. I'm talking abourt encoding.
You might have noticed that iTunes performance is always in new computer speed tests. Even PC tech sites use it to test new cpus.
If I'm ripping one of my CD's, I'd like to have it rip 8 songs at once on an 8 core machine, and get it over with.
If I'm ripping one of my CD's, I'd like to have it rip 8 songs at once on an 8 core machine, and get it over with.
That would be nice, but is it really worth having a computer with eight optical drives as well? That's what it would take to do that, minimum. I think it might be sixteen drives because the limiting factor is the drive, not the CPU. On my Mac Pro, ripping and encoding takes a negligible amount of CPU power, the CPU is almost always idling, waiting for the drive.
Yeah, I understand. Even in that case, there is a part of the process that can't be parallelized, the cd-ripping. I only use Max to rip and convert my songs, and even if I can specify 4 threads for the conversion process, it usually only encodes a song at a time, as that's as fast as the cd-ripping process can get the data from the cd. Sometimes it get's to do 2 for a short while at the same time, but usually that's just a few times.
I don't know how the process is done in iTunes... I usually stop hearing the cd spinning in the drive before it has finished up doing the conversions in the screen, so it might be reading the cd in a thread and doing the conversion in another one, in which case, from what I have seen with Max, is usually as fast as you can go. As usual, the bottleneck there is the I/O, not the cpu speed/cores per se.
Anyway, I do see your point, and I hope Apple, and the other big houses at least, start promoting and moving into a multithreaded methodology where it fits.
That would be nice, but is it really worth having a computer with eight optical drives as well? That's what it would take to do that, minimum. I think it might be sixteen drives because the limiting factor is the drive, not the CPU. On my Mac Pro, ripping and encoding takes a negligible amount of CPU power, the CPU is almost always idling, waiting for the drive.
No, it wouldn't.
A drive reads data out much faster than it can play it. I'd like to see iTunes read the drive as data, which it could do, if the software allowed it to. Then it could be read in at 32 to 50 times the speed.
Only one drive would be required. It's just a matter of the drive appearing on the desktop as data, which it can.
A drive reads data out much faster than it can play it. I'd like to see iTunes read the drive as data, which it could do, if the software allowed it to. Then it could be read in at 32 to 50 times the speed.
Only one drive would be required. It's just a matter of the drive appearing on the desktop as data, which it can.
Your computer is not going to read 50x faster than it already rips, if that's what you are saying, unless your computer only rips at real time, which is 1x, meaning that a 45 minute CD takes 45 minutes to rip. iTunes isn't that stupid. With the aggressive error correction turned on, my drive is already ripping at an average of 20x or so with iTunes, making it about a three minute rip. Even at that rate, the additional load is barely different from idle in Activity Monitor. At most, with your hypothetical example, you might double the rip speed at most, but there are still problems with that just because the drive can only spin the disc so much before risking disc fragmentation, so you can only hope to get 50x or so at the 80 minute mark.
Your computer is not going to read 50x faster than it already rips, if that's what you are saying, unless your computer only rips at real time, which is 1x, meaning that a 45 minute CD takes 45 minutes to rip. iTunes isn't that stupid. With the aggressive error correction turned on, my drive is already ripping at an average of 20x or so with iTunes, making it about a three minute rip. Even at that rate, the additional load is barely different from idle in Activity Monitor. At most, with your hypothetical example, you might double the rip speed at most, but there are still problems with that just because the drive can only spin the disc so much before risking disc fragmentation, so you can only hope to get 50x or so at the 80 minute mark.
I don't agree with that entirely. A 100% speedup is certainly possible from drive speeds alone. Fragmentation shouldn't be a problem with modern, large, drives. If Apple chose to, iTunes could seek out an open space more than large enough to accommodate the (nowadays) small footprint of a CD. That's one advantage of owning the OS.
I currently use two computers. The one I'm on the internet with is an Audio G4, upgraded with a dual 1.8 GHz 7447a card from Powerlogix. This machine is pretty slow today as far as moving things from the CD. My dual 1 GHz G5 is noticeably faster
I just copied a music CD I have sitting on my desk, to an external SATA drive connected to my G4. It is 634 MB. It took 2:26 for the data to get copied. My DVD recorder is a Pioneer 109 with a slow 32x CD speed.
My estimate (from experience doing this) is that on the G5, it would have taken about 1:45. Still not the fastest speed achievable.
With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
.....With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
I'd actually have to read that somewhere extremely tech savvy, and still probably have to see it to believe it.
I remember seeing somewhere (Mythbusters maybe??) some tests about how fast can you spin a CD before it would destroy itself. Unfortunately I don't remember the number, to be honest, but it was clear that you get to a point where the CD will just break. You don't want that to happen in your Mac Pro :-)
I have just converted a CD using Max, just to see how long will it took. It was Discovery, from Daft Punk, it's 616Mb, 1hour according to iTunes. It took 2:53.4 to rip and convert it. The conversion threads ended about 15-20 seconds after the ripping, basically what the last song to be extracted took to convert. It's about 20x. If the CD could be read much faster, say, 32x or 40x, it could have took maybe 2 mins or so to encode (encoding the already extracted songs it's going to take maybe 70 seconds or so in total, having a 8 core machine could reduce this to maybe 35 seconds, but still, you get as fast basically as the CD can provide you with data. And it can't give you several tracks at once, so you don't have other option but process them in a serial way, except, of course, if a song came and you're still processing another one, where you could use another thread (basically what Max does). iTunes converted this CD in 3:19.4... so it's not that bad actually.
At the end, you are not going to get instantaneous conversion, it does use CPU power to convert a song to another format, about 20 seconds to convert a 10 minute son, at least with the params I'm using here (AAC, 192kbps, maximum quality) in my Mac Pro (4x2.66, 5gb ram) I guess that the fast you can go is with WAV or RAW data, where, of course, the speed is limited by the CD drive, and that can't be multithreaded.
I don't agree with that entirely. A 100% speedup is certainly possible from drive speeds alone. Fragmentation shouldn't be a problem with modern, large, drives. If Apple chose to, iTunes could seek out an open space more than large enough to accommodate the (nowadays) small footprint of a CD. That's one advantage of owning the OS.
Fragmentation as in the optical disc shattering not multiple bits of files scattered about. It's probably not a significant risk, but that's the problem with going to a 60x CD drive and I think pretty much why they don't exist, the makers don't want to take the liability because of a one in a million injury. As such, the drive can't read from the center of the disc any faster than 32x, 50x+ speeds are only attainable at the perimeter of the disc.
Quote:
With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
That's already happening. The drive, regardless of the read mode, doesn't even take the power of half a core to encode as it rips from the drive. I think the single core can encode 192kbps AAC from a WAV/AIFF ripped from an optical drive at more than 100x real time. A rip+encode only takes a few seconds longer than a straight rip.
I remember seeing somewhere (Mythbusters maybe??) some tests about how fast can you spin a CD before it would destroy itself. Unfortunately I don't remember the number, to be honest, but it was clear that you get to a point where the CD will just break. You don't want that to happen in your Mac Pro :-)
I have just converted a CD using Max, just to see how long will it took. It was Discovery, from Daft Punk, it's 616Mb, 1hour according to iTunes. It took 2:53.4 to rip and convert it. The conversion threads ended about 15-20 seconds after the ripping, basically what the last song to be extracted took to convert. It's about 20x. If the CD could be read much faster, say, 32x or 40x, it could have took maybe 2 mins or so to encode (encoding the already extracted songs it's going to take maybe 70 seconds or so in total, having a 8 core machine could reduce this to maybe 35 seconds, but still, you get as fast basically as the CD can provide you with data. And it can't give you several tracks at once, so you don't have other option but process them in a serial way, except, of course, if a song came and you're still processing another one, where you could use another thread (basically what Max does). iTunes converted this CD in 3:19.4... so it's not that bad actually.
At the end, you are not going to get instantaneous conversion, it does use CPU power to convert a song to another format, about 20 seconds to convert a 10 minute son, at least with the params I'm using here (AAC, 192kbps, maximum quality) in my Mac Pro (4x2.66, 5gb ram) I guess that the fast you can go is with WAV or RAW data, where, of course, the speed is limited by the CD drive, and that can't be multithreaded.
Regards,
We're not talking about spinning a Cd at prodigious rates. Just the rates allowed by the fastest drives, a max of 52x I believe.
Depending on the speed of the individual core, and the speed of the drive, you could get more than one song being ripped at a time, as more songs end up on the HD. How many would depend on those factors
When I said 8, before, I was thinking of the theoretical limit of the computer. Other factors are involved, which would cut that down, of course.
Fragmentation as in the optical disc shattering not multiple bits of files scattered about. It's probably not a significant risk, but that's the problem with going to a 60x CD drive and I think pretty much why they don't exist, the makers don't want to take the liability because of a one in a million injury. As such, the drive can't read from the center of the disc any faster than 32x, 50x+ speeds are only attainable at the perimeter of the disc.
I don't know what you mean by that. Songs are recorded sequentionally, as a piece, in order.
There is the Grey Code database, that's true, but it isn't encoded within the song files.
Quote:
That's already happening. The drive, regardless of the read mode, doesn't even take the power of half a core to encode as it rips from the drive. I think the single core can encode 192kbps AAC from a WAV/AIFF ripped from an optical drive at more than 100x real time. A rip+encode only takes a few seconds longer than a straight rip.
It depends on the machine. When I first started doing this, years ago, it took three times as long as the play time of the song to rip it. It just keeps getting faster. There is no limit to the speed that it can be ripped, other than the time it takes to get the song off the disk.
Even there, I've been told that a song could be ripped as it comes off the disk, on its way to the drive.
Reviews that use itunes as a test, have had comments that it is too bad that Apple hasn't as yet opened iTunes to the possibility of using more cores. There has been a lot of commenting over this.
It may seem trivial, but I merely used it as an example.
We're not talking about spinning a Cd at prodigious rates. Just the rates allowed by the fastest drives, a max of 52x I believe.
Depending on the speed of the individual core, and the speed of the drive, you could get more than one song being ripped at a time, as more songs end up on the HD. How many would depend on those factors
When I said 8, before, I was thinking of the theoretical limit of the computer. Other factors are involved, which would cut that down, of course.
But, much higher speeds are certainly possible.
With existing drives, the best you can hope for is the 100% speedup that you suggested before, but certainly not such that you can max out a four core machine, much less an eight core machine. Adding more cores to the mix doesn't change much because the optical drive is by far the limiting factor. The optical drive reads a single thing at a time at its best speed, to read more than one thing at a time, the sum of data extraction speed is still less than reading linearly.
With existing drives, the best you can hope for is the 100% speedup that you suggested before, but certainly not such that you can max out a four core machine, much less an eight core machine. Adding more cores to the mix doesn't change much because the optical drive is by far the limiting factor. The optical drive reads a single thing at a time at its best speed, to read more than one thing at a time, the sum of data extraction speed is still less than reading linearly.
That's why I said 2x, because of the drive.
Of course, if you copy CD's to the HD, then rip them, it can go much faster. There are times when I've done that to save MY time, rather than my computers, because they have nothing better to do. In that case, the more threads the better.
Of course, if you copy CD's to the HD, then rip them, it can go much faster.
Agreed, at least on the encoding part. The extraction from CD and copying to HD isn't any different.
Quote:
There are times when I've done that to save MY time, rather than my computers, because they have nothing better to do. In that case, the more threads the better.
I don't really understand this, because I've never found this to make a very unnoticeable difference in how much human time it takes. I think the last time I've done this, it was fifteen seconds on a three minute rip. If you really are still using a G4 then maybe it would be more than fifteen seconds.
Agreed, at least on the encoding part. The extraction from CD and copying to HD isn't any different.
I don't really understand this, because I've never found this to make a very unnoticeable difference in how much human time it takes. I think the last time I've done this, it was fifteen seconds on a three minute rip. If you really are still using a G4 then maybe it would be more than fifteen seconds.
What I find to be interesting is that there isn't as much of a speedup between machines as people think. My dual G5 doesn't encode much faster than my dual G4, and a friends dual Intel doesn't encode much faster than my G5.
What I find to be interesting is that there isn't as much of a speedup between machines as people think. My dual G5 doesn't encode much faster than my dual G4, and a friends dual Intel doesn't encode much faster than my G5.
Do you think the next instruction set from Intel on the upcoming chips will fix this if Apple takes advantage of this?
Comments
I'd argue that the apps you say don't use cores could, but the users hardly need a mac pro for those apps regardless.
Look at some of Apple's own programs, such as the consumer apps. Even those that should use 4 and even 8 cores don't. Look to iTunes, for example. Two cores. Why? No good reason at all. Just lazyness on the part of Apple.
There are plenty of other prgogams in that same situation. They could throw out more threads, but they don't. Performance suffers.
But, more cores do benefit you if you do several tasks at once, even now.
People right here have been calling for 4 core iMacs and portables, so it would be nice if all of those programs that would benefit from the use of more cores would do so.
But they will eventually.
You say about iTunes... well... why would you need more than 2 threads in the usual work for iTunes? I don't see the point. You won't be listening two or more tracks at the same time, right? (And I'm sure that if that was/is possible in iTunes, you will get two different threads to play each one a track) Where you could "easily" have some multithreading is in the ripping or conversion process, there you can usually fire two or more threads to convert each one a file. But not much people have more than 1 cd drive, and you can only read single-threaded the cd... in any case, it is somewhat feasible to have that, and for instance, Max does it and very very well, specially the file conversion process, there you can easily get a big boost if you enable more than one thread. The ripping sees a boost, but it's not near to linear at all.
Multithreading IS the future, I'm convinced of that, but in many cases, if not the majority, the big advantage for the consumer will be being able to use 3 or 4 apps, "heavy" apps, without problems, at the same time. And that you can have it right now, even with single-threaded apps, and not-really-state-of-the-art schedulers. Those apps that could have taken advantage of multiple processors have already taken it, maybe not 100%, but near. And they will continue to improve, that's for sure, because that's what the market demands, but there is stuff that you just can't convert to multithread.
I fear that we will get another Mhz myth, but this time with multithreads. They are tools, not the silver bullet to solve all of our needs. At some point people wil realize that, and the industry will have to move to the next big thing.
In any cases, interesting times :-)
Regards,
Rodrigo Gómez
Well, I know from my own experience that it's not just magically add threads to your program and voila! you have a multithreaded app. There are things that scale linearly with the number of cores that you have, and a lot of other things that do not. Even the ones that scale well are usually restricted by the memory bus or the I/O.
You say about iTunes... well... why would you need more than 2 threads in the usual work for iTunes? I don't see the point. You won't be listening two or more tracks at the same time, right? (And I'm sure that if that was/is possible in iTunes, you will get two different threads to play each one a track) Where you could "easily" have some multithreading is in the ripping or conversion process, there you can usually fire two or more threads to convert each one a file. But not much people have more than 1 cd drive, and you can only read single-threaded the cd... in any case, it is somewhat feasible to have that, and for instance, Max does it and very very well, specially the file conversion process, there you can easily get a big boost if you enable more than one thread. The ripping sees a boost, but it's not near to linear at all.
Multithreading IS the future, I'm convinced of that, but in many cases, if not the majority, the big advantage for the consumer will be being able to use 3 or 4 apps, "heavy" apps, without problems, at the same time. And that you can have it right now, even with single-threaded apps, and not-really-state-of-the-art schedulers. Those apps that could have taken advantage of multiple processors have already taken it, maybe not 100%, but near. And they will continue to improve, that's for sure, because that's what the market demands, but there is stuff that you just can't convert to multithread.
I fear that we will get another Mhz myth, but this time with multithreads. They are tools, not the silver bullet to solve all of our needs. At some point people wil realize that, and the industry will have to move to the next big thing.
In any cases, interesting times :-)
Regards,
Rodrigo Gómez
I'm not talking about playing. I'm talking abourt encoding.
You might have noticed that iTunes performance is always in new computer speed tests. Even PC tech sites use it to test new cpus.
If I'm ripping one of my CD's, I'd like to have it rip 8 songs at once on an 8 core machine, and get it over with.
If I'm ripping one of my CD's, I'd like to have it rip 8 songs at once on an 8 core machine, and get it over with.
That would be nice, but is it really worth having a computer with eight optical drives as well? That's what it would take to do that, minimum. I think it might be sixteen drives because the limiting factor is the drive, not the CPU. On my Mac Pro, ripping and encoding takes a negligible amount of CPU power, the CPU is almost always idling, waiting for the drive.
Yeah, I understand. Even in that case, there is a part of the process that can't be parallelized, the cd-ripping. I only use Max to rip and convert my songs, and even if I can specify 4 threads for the conversion process, it usually only encodes a song at a time, as that's as fast as the cd-ripping process can get the data from the cd. Sometimes it get's to do 2 for a short while at the same time, but usually that's just a few times.
I don't know how the process is done in iTunes... I usually stop hearing the cd spinning in the drive before it has finished up doing the conversions in the screen, so it might be reading the cd in a thread and doing the conversion in another one, in which case, from what I have seen with Max, is usually as fast as you can go. As usual, the bottleneck there is the I/O, not the cpu speed/cores per se.
Anyway, I do see your point, and I hope Apple, and the other big houses at least, start promoting and moving into a multithreaded methodology where it fits.
Regards,
Rodrigo Gómez
That would be nice, but is it really worth having a computer with eight optical drives as well? That's what it would take to do that, minimum. I think it might be sixteen drives because the limiting factor is the drive, not the CPU. On my Mac Pro, ripping and encoding takes a negligible amount of CPU power, the CPU is almost always idling, waiting for the drive.
No, it wouldn't.
A drive reads data out much faster than it can play it. I'd like to see iTunes read the drive as data, which it could do, if the software allowed it to. Then it could be read in at 32 to 50 times the speed.
Only one drive would be required. It's just a matter of the drive appearing on the desktop as data, which it can.
No, it wouldn't.
A drive reads data out much faster than it can play it. I'd like to see iTunes read the drive as data, which it could do, if the software allowed it to. Then it could be read in at 32 to 50 times the speed.
Only one drive would be required. It's just a matter of the drive appearing on the desktop as data, which it can.
Your computer is not going to read 50x faster than it already rips, if that's what you are saying, unless your computer only rips at real time, which is 1x, meaning that a 45 minute CD takes 45 minutes to rip. iTunes isn't that stupid. With the aggressive error correction turned on, my drive is already ripping at an average of 20x or so with iTunes, making it about a three minute rip. Even at that rate, the additional load is barely different from idle in Activity Monitor. At most, with your hypothetical example, you might double the rip speed at most, but there are still problems with that just because the drive can only spin the disc so much before risking disc fragmentation, so you can only hope to get 50x or so at the 80 minute mark.
Your computer is not going to read 50x faster than it already rips, if that's what you are saying, unless your computer only rips at real time, which is 1x, meaning that a 45 minute CD takes 45 minutes to rip. iTunes isn't that stupid. With the aggressive error correction turned on, my drive is already ripping at an average of 20x or so with iTunes, making it about a three minute rip. Even at that rate, the additional load is barely different from idle in Activity Monitor. At most, with your hypothetical example, you might double the rip speed at most, but there are still problems with that just because the drive can only spin the disc so much before risking disc fragmentation, so you can only hope to get 50x or so at the 80 minute mark.
I don't agree with that entirely. A 100% speedup is certainly possible from drive speeds alone. Fragmentation shouldn't be a problem with modern, large, drives. If Apple chose to, iTunes could seek out an open space more than large enough to accommodate the (nowadays) small footprint of a CD. That's one advantage of owning the OS.
I currently use two computers. The one I'm on the internet with is an Audio G4, upgraded with a dual 1.8 GHz 7447a card from Powerlogix. This machine is pretty slow today as far as moving things from the CD. My dual 1 GHz G5 is noticeably faster
I just copied a music CD I have sitting on my desk, to an external SATA drive connected to my G4. It is 634 MB. It took 2:26 for the data to get copied. My DVD recorder is a Pioneer 109 with a slow 32x CD speed.
My estimate (from experience doing this) is that on the G5, it would have taken about 1:45. Still not the fastest speed achievable.
With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
.....With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
I'd actually have to read that somewhere extremely tech savvy, and still probably have to see it to believe it.
I'd actually have to read that somewhere extremely tech savvy, and still probably have to see it to believe it.
I didn't say it could be done now.
I have just converted a CD using Max, just to see how long will it took. It was Discovery, from Daft Punk, it's 616Mb, 1hour according to iTunes. It took 2:53.4 to rip and convert it. The conversion threads ended about 15-20 seconds after the ripping, basically what the last song to be extracted took to convert. It's about 20x. If the CD could be read much faster, say, 32x or 40x, it could have took maybe 2 mins or so to encode (encoding the already extracted songs it's going to take maybe 70 seconds or so in total, having a 8 core machine could reduce this to maybe 35 seconds, but still, you get as fast basically as the CD can provide you with data. And it can't give you several tracks at once, so you don't have other option but process them in a serial way, except, of course, if a song came and you're still processing another one, where you could use another thread (basically what Max does). iTunes converted this CD in 3:19.4... so it's not that bad actually.
At the end, you are not going to get instantaneous conversion, it does use CPU power to convert a song to another format, about 20 seconds to convert a 10 minute son, at least with the params I'm using here (AAC, 192kbps, maximum quality) in my Mac Pro (4x2.66, 5gb ram) I guess that the fast you can go is with WAV or RAW data, where, of course, the speed is limited by the CD drive, and that can't be multithreaded.
Regards,
I don't agree with that entirely. A 100% speedup is certainly possible from drive speeds alone. Fragmentation shouldn't be a problem with modern, large, drives. If Apple chose to, iTunes could seek out an open space more than large enough to accommodate the (nowadays) small footprint of a CD. That's one advantage of owning the OS.
Fragmentation as in the optical disc shattering not multiple bits of files scattered about. It's probably not a significant risk, but that's the problem with going to a 60x CD drive and I think pretty much why they don't exist, the makers don't want to take the liability because of a one in a million injury. As such, the drive can't read from the center of the disc any faster than 32x, 50x+ speeds are only attainable at the perimeter of the disc.
With a bunch of cores powered up and ready, a song could be ripped as soon as it became available. The entire album could be ripped in not much more time than it took to read the data in.
That's already happening. The drive, regardless of the read mode, doesn't even take the power of half a core to encode as it rips from the drive. I think the single core can encode 192kbps AAC from a WAV/AIFF ripped from an optical drive at more than 100x real time. A rip+encode only takes a few seconds longer than a straight rip.
I remember seeing somewhere (Mythbusters maybe??) some tests about how fast can you spin a CD before it would destroy itself. Unfortunately I don't remember the number, to be honest, but it was clear that you get to a point where the CD will just break. You don't want that to happen in your Mac Pro :-)
I have just converted a CD using Max, just to see how long will it took. It was Discovery, from Daft Punk, it's 616Mb, 1hour according to iTunes. It took 2:53.4 to rip and convert it. The conversion threads ended about 15-20 seconds after the ripping, basically what the last song to be extracted took to convert. It's about 20x. If the CD could be read much faster, say, 32x or 40x, it could have took maybe 2 mins or so to encode (encoding the already extracted songs it's going to take maybe 70 seconds or so in total, having a 8 core machine could reduce this to maybe 35 seconds, but still, you get as fast basically as the CD can provide you with data. And it can't give you several tracks at once, so you don't have other option but process them in a serial way, except, of course, if a song came and you're still processing another one, where you could use another thread (basically what Max does). iTunes converted this CD in 3:19.4... so it's not that bad actually.
At the end, you are not going to get instantaneous conversion, it does use CPU power to convert a song to another format, about 20 seconds to convert a 10 minute son, at least with the params I'm using here (AAC, 192kbps, maximum quality) in my Mac Pro (4x2.66, 5gb ram) I guess that the fast you can go is with WAV or RAW data, where, of course, the speed is limited by the CD drive, and that can't be multithreaded.
Regards,
We're not talking about spinning a Cd at prodigious rates. Just the rates allowed by the fastest drives, a max of 52x I believe.
Depending on the speed of the individual core, and the speed of the drive, you could get more than one song being ripped at a time, as more songs end up on the HD. How many would depend on those factors
When I said 8, before, I was thinking of the theoretical limit of the computer. Other factors are involved, which would cut that down, of course.
But, much higher speeds are certainly possible.
Fragmentation as in the optical disc shattering not multiple bits of files scattered about. It's probably not a significant risk, but that's the problem with going to a 60x CD drive and I think pretty much why they don't exist, the makers don't want to take the liability because of a one in a million injury. As such, the drive can't read from the center of the disc any faster than 32x, 50x+ speeds are only attainable at the perimeter of the disc.
I don't know what you mean by that. Songs are recorded sequentionally, as a piece, in order.
There is the Grey Code database, that's true, but it isn't encoded within the song files.
That's already happening. The drive, regardless of the read mode, doesn't even take the power of half a core to encode as it rips from the drive. I think the single core can encode 192kbps AAC from a WAV/AIFF ripped from an optical drive at more than 100x real time. A rip+encode only takes a few seconds longer than a straight rip.
It depends on the machine. When I first started doing this, years ago, it took three times as long as the play time of the song to rip it. It just keeps getting faster. There is no limit to the speed that it can be ripped, other than the time it takes to get the song off the disk.
Even there, I've been told that a song could be ripped as it comes off the disk, on its way to the drive.
Reviews that use itunes as a test, have had comments that it is too bad that Apple hasn't as yet opened iTunes to the possibility of using more cores. There has been a lot of commenting over this.
It may seem trivial, but I merely used it as an example.
We're not talking about spinning a Cd at prodigious rates. Just the rates allowed by the fastest drives, a max of 52x I believe.
Depending on the speed of the individual core, and the speed of the drive, you could get more than one song being ripped at a time, as more songs end up on the HD. How many would depend on those factors
When I said 8, before, I was thinking of the theoretical limit of the computer. Other factors are involved, which would cut that down, of course.
But, much higher speeds are certainly possible.
With existing drives, the best you can hope for is the 100% speedup that you suggested before, but certainly not such that you can max out a four core machine, much less an eight core machine. Adding more cores to the mix doesn't change much because the optical drive is by far the limiting factor. The optical drive reads a single thing at a time at its best speed, to read more than one thing at a time, the sum of data extraction speed is still less than reading linearly.
With existing drives, the best you can hope for is the 100% speedup that you suggested before, but certainly not such that you can max out a four core machine, much less an eight core machine. Adding more cores to the mix doesn't change much because the optical drive is by far the limiting factor. The optical drive reads a single thing at a time at its best speed, to read more than one thing at a time, the sum of data extraction speed is still less than reading linearly.
That's why I said 2x, because of the drive.
Of course, if you copy CD's to the HD, then rip them, it can go much faster. There are times when I've done that to save MY time, rather than my computers, because they have nothing better to do. In that case, the more threads the better.
Of course, if you copy CD's to the HD, then rip them, it can go much faster.
Agreed, at least on the encoding part. The extraction from CD and copying to HD isn't any different.
There are times when I've done that to save MY time, rather than my computers, because they have nothing better to do. In that case, the more threads the better.
I don't really understand this, because I've never found this to make a very unnoticeable difference in how much human time it takes. I think the last time I've done this, it was fifteen seconds on a three minute rip. If you really are still using a G4 then maybe it would be more than fifteen seconds.
Agreed, at least on the encoding part. The extraction from CD and copying to HD isn't any different.
I don't really understand this, because I've never found this to make a very unnoticeable difference in how much human time it takes. I think the last time I've done this, it was fifteen seconds on a three minute rip. If you really are still using a G4 then maybe it would be more than fifteen seconds.
What I find to be interesting is that there isn't as much of a speedup between machines as people think. My dual G5 doesn't encode much faster than my dual G4, and a friends dual Intel doesn't encode much faster than my G5.
What I find to be interesting is that there isn't as much of a speedup between machines as people think. My dual G5 doesn't encode much faster than my dual G4, and a friends dual Intel doesn't encode much faster than my G5.
Do you think the next instruction set from Intel on the upcoming chips will fix this if Apple takes advantage of this?