We used that term several years ago to mean that the songs would get burned to the Cd as soon as they were ripped. so we used to say that we ripped to a CD. The speeds he was mentioning came across that way.
Going from another thread, I think it may be that the current Pentium Ms (not the Yonah & Merom ones that Apple will use) don't do a great job with SSE code, which iTunes uses to help speed encoding when it's present. I've seen Pentium 4 systems absolutely fly when ripping CDs, so it has little to do with the OS.
It's because there was a way to have it burn to the disk as it was ripping. It never went to the HD. I haven't ripped music files for a while, so I'm not sure if it can still be done, though I don't see why not.
Going from another thread, I think it may be that the current Pentium Ms (not the Yonah & Merom ones that Apple will use) don't do a great job with SSE code, which iTunes uses to help speed encoding when it's present. I've seen Pentium 4 systems absolutely fly when ripping CDs, so it has little to do with the OS.
Of course it's current x86's. How could they test it with chips that aren't out yet?
XBench is now a universal binary too. That's not to say VecLib is I guess but Apple have a lot of optimizing to do or Intel has some serious catching up to do.
XBench is now a universal binary too. That's not to say VecLib is I guess but Apple have a lot of optimizing to do or Intel has some serious catching up to do.
I'm careful with X Bench. It's a godawful program.
I'm careful with X Bench. It's a godawful program.
Too true but until someone does some proper testing, and not just running Doom or Quake 3, that's what we've got.
If the developer has simply just flicked on the 'Compile for Intel' switch and that's what happens, it's maybe not good. It's not exactly real world though.
Perhaps we should run an iTunes bake-off since there's a Windows and a Mac version.
Too true but until someone does some proper testing, and not just running Doom or Quake 3, that's what we've got.
If the developer has simply just flicked on the 'Compile for Intel' switch and that's what happens, it's maybe not good. It's not exactly real world though.
Perhaps we should run an iTunes bake-off since there's a Windows and a Mac version.
That's really the only to do it. If we can assume that Apple optimized BOTH versions.
We don't always know if it's the software or the hardware. Even the testing programs are subject to that kind of problem. The compiler makes a difference etc. The PC world has more options.
That's really the only to do it. If we can assume that Apple optimized BOTH versions.
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
You don't know that. Just because something takes time to do doesn't mean that it's written poorly, or that it isn't optimized. Perhaps it is highly optimized, and if it weren't, it would be much worse. Unless you can get to the source code you won't be able to tell. Unless another ripping program performed much better, there would be no useful comparison.
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
I disagree.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
You could repeat the test with other programs available on both platforms.
In this case however, the codec code is small and highly optimized *usually*. I just think this is one case where the G4/G5 rules. There are other specific tests with Photoshop filters, some of which are an order faster on PPC than Intel.
And that situation is going to get better with the 7448 as it does out of order altivec instruction processing.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
You could repeat the test with other programs available on both platforms.
In this case however, the codec code is small and highly optimized *usually*. I just think this is one case where the G4/G5 rules. There are other specific tests with Photoshop filters, some of which are an order faster on PPC than Intel.
And that situation is going to get better with the 7448 as it does out of order altivec instruction processing.
Ok, here's something I can speak to with some authority. I've been beta testing Photoshop from pretty much the beginning.
Right now, PS is a tangle of code. I don't mean that the program itself is a mess. They fixed that with version 5. What I mean is that some of the program is optimized for x86, SSE, and some for PPC Altivec. The program can detect, to a certain extent, which processor it's running on, and execute the best code.
But some filters are optimized for one platform or the other. Some aren't optimized at all.
Without knowing what is what, it's a crap shoot. That's why both Apple and x86 testers can find areas in which they are right.
Adobe, like many other cross-platform software houses, is loathe to give one platform an advantage over the other.
Adobe, like many other cross-platform software houses, is loathe to give one platform an advantage over the other.
Again, it doesn't really matter if they've optimized bits for either platform. I, as a user, just want the fastest platform.
Adobe however are wrong to show such indifference to their users of either platform and it's highly annoying. If they didn't have such a stranglehold on the 'photoshop' market then they'd not get away with that attitude and someone would come in with a fully optimized package. It's happened before - see Apple and FinalCut v Premiere. Or for that matter, Bibble and their RAW tools.
Again, it doesn't really matter if they've optimized bits for either platform. I, as a user, just want the fastest platform.
Adobe however are wrong to show such indifference to their users of either platform and it's highly annoying. If they didn't have such a stranglehold on the 'photoshop' market then they'd not get away with that attitude and someone would come in with a fully optimized package. It's happened before - see Apple and FinalCut v Premiere. Or for that matter, Bibble and their RAW tools.
It's not going to happen. Apple would have to want to compete, and they can't. Bibble is a *very* small software house. The major ones have to think differently.
I'm with you. I wish they would do this. I, and others, have argued with Adobe about this, but they believe that it would damage their business.
I'd like to talk more, but I'm out of time for now.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
Aegis,
It would be interesting to see the difference between iTunes mp3 and aac encoding on both platforms. I remember when aac first became available on the mac, my encode times suffered (in comparison to when I was ripping into mp3). Perhaps Windows machines are only relatively slow with aac encoding (which I've read gains a big boost from altivec) and less so with mp3?
It would be interesting to see the difference between iTunes mp3 and aac encoding on both platforms. I remember when aac first became available on the mac, my encode times suffered (in comparison to when I was ripping into mp3). Perhaps Windows machines are only relatively slow with aac encoding (which I've read gains a big boost from altivec) and less so with mp3?
Any time an encoding/decoding algorithm encodes/decodes for a smaller file or a higher quality file, it's going to take more computing resourses.
H.264 takes about four times as much computing power than does MPEG 2 for the same file. But it produces a significantly smaller result, with better quality.
I've seen the same thing with PS. Adobe would come out with new or better filters, only to abandon them at the time because computers weren't up to it yet
MP3 is pretty simple, and not very good. It was invented when computers were a fraction as powerful as they are now.
Even now, very few personal computers can decode 1080p H.264. Three years ago there weren't any in the home that could. In two years time all will.
windows media 10HIDEF is virtually the same specs of quality and compression as h.264. On windows this codec plays fine on even the lowly celeron. Even 3rd party h.264 hi-def content plays fine (not just wmv) either the machines I'm using (lowly laptops, take advantge of video card functions or windows is just more effient)
either way if apple plans to play hd on these new laptops they better come with a onboard chip for this (hopefully in way of new video cards) Apple is netorious for shipping cards with nice onboard hardware features and not taking advantage of them in laptops.
Quote:
Originally posted by melgross
Any time an encoding/decoding algorithm encodes/decodes for a smaller file or a higher quality file, it's going to take more computing resourses.
H.264 takes about four times as much computing power than does MPEG 2 for the same file. But it produces a significantly smaller result, with better quality.
I've seen the same thing with PS. Adobe would come out with new or better filters, only to abandon them at the time because computers weren't up to it yet
MP3 is pretty simple, and not very good. It was invented when computers were a fraction as powerful as they are now.
Even now, very few personal computers can decode 1080p H.264. Three years ago there weren't any in the home that could. In two years time all will.
Comments
Originally posted by aegisdesign
I was ripping standard audio CDs, not burning.
Ok. Many people rip to a CD. The info doesn't hurt.
Originally posted by Gene Clean
How do you rip to a CD?
We used that term several years ago to mean that the songs would get burned to the Cd as soon as they were ripped. so we used to say that we ripped to a CD. The speeds he was mentioning came across that way.
http://www.theapplecollection.com/Co..._long_144.html
Originally posted by aegisdesign
I've never used 'Rip' in the 'to' sense, always in the way Apple intended....
http://www.theapplecollection.com/Co..._long_144.html
It's because there was a way to have it burn to the disk as it was ripping. It never went to the HD. I haven't ripped music files for a while, so I'm not sure if it can still be done, though I don't see why not.
Originally posted by Commodus
Going from another thread, I think it may be that the current Pentium Ms (not the Yonah & Merom ones that Apple will use) don't do a great job with SSE code, which iTunes uses to help speed encoding when it's present. I've seen Pentium 4 systems absolutely fly when ripping CDs, so it has little to do with the OS.
Of course it's current x86's. How could they test it with chips that aren't out yet?
Originally posted by melgross
Of course it's current x86's. How could they test it with chips that aren't out yet?
It was probably me in the other thread. ;-)
The XBench benchmarks for the Intel developer system show the VecLib code as being over 6 times slower on intel than even a G4 Powerbook.
http://ladd.dyndns.org/xbench/merge....41&doc2=126268
XBench is now a universal binary too. That's not to say VecLib is I guess but Apple have a lot of optimizing to do or Intel has some serious catching up to do.
Originally posted by aegisdesign
It was probably me in the other thread. ;-)
The XBench benchmarks for the Intel developer system show the VecLib code as being over 6 times slower on intel than even a G4 Powerbook.
http://ladd.dyndns.org/xbench/merge....41&doc2=126268
XBench is now a universal binary too. That's not to say VecLib is I guess but Apple have a lot of optimizing to do or Intel has some serious catching up to do.
I'm careful with X Bench. It's a godawful program.
Originally posted by melgross
I'm careful with X Bench. It's a godawful program.
Too true but until someone does some proper testing, and not just running Doom or Quake 3, that's what we've got.
If the developer has simply just flicked on the 'Compile for Intel' switch and that's what happens, it's maybe not good. It's not exactly real world though.
Perhaps we should run an iTunes bake-off since there's a Windows and a Mac version.
Originally posted by aegisdesign
Too true but until someone does some proper testing, and not just running Doom or Quake 3, that's what we've got.
If the developer has simply just flicked on the 'Compile for Intel' switch and that's what happens, it's maybe not good. It's not exactly real world though.
Perhaps we should run an iTunes bake-off since there's a Windows and a Mac version.
That's really the only to do it. If we can assume that Apple optimized BOTH versions.
We don't always know if it's the software or the hardware. Even the testing programs are subject to that kind of problem. The compiler makes a difference etc. The PC world has more options.
Originally posted by melgross
That's really the only to do it. If we can assume that Apple optimized BOTH versions.
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
Originally posted by kim kap sol
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
You don't know that. Just because something takes time to do doesn't mean that it's written poorly, or that it isn't optimized. Perhaps it is highly optimized, and if it weren't, it would be much worse. Unless you can get to the source code you won't be able to tell. Unless another ripping program performed much better, there would be no useful comparison.
edit: changed "If" to "Unless" you...
Originally posted by kim kap sol
But they most certainly haven't. iTunes is poor on both Mac and PC. QuickTime is especially poor on PCs. It's just way too difficult to do cross-platform benchmarking in a controlled way.
I disagree.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
You could repeat the test with other programs available on both platforms.
In this case however, the codec code is small and highly optimized *usually*. I just think this is one case where the G4/G5 rules. There are other specific tests with Photoshop filters, some of which are an order faster on PPC than Intel.
And that situation is going to get better with the 7448 as it does out of order altivec instruction processing.
Originally posted by aegisdesign
I disagree.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
You could repeat the test with other programs available on both platforms.
In this case however, the codec code is small and highly optimized *usually*. I just think this is one case where the G4/G5 rules. There are other specific tests with Photoshop filters, some of which are an order faster on PPC than Intel.
And that situation is going to get better with the 7448 as it does out of order altivec instruction processing.
Ok, here's something I can speak to with some authority. I've been beta testing Photoshop from pretty much the beginning.
Right now, PS is a tangle of code. I don't mean that the program itself is a mess. They fixed that with version 5. What I mean is that some of the program is optimized for x86, SSE, and some for PPC Altivec. The program can detect, to a certain extent, which processor it's running on, and execute the best code.
But some filters are optimized for one platform or the other. Some aren't optimized at all.
Without knowing what is what, it's a crap shoot. That's why both Apple and x86 testers can find areas in which they are right.
Adobe, like many other cross-platform software houses, is loathe to give one platform an advantage over the other.
Originally posted by melgross
Adobe, like many other cross-platform software houses, is loathe to give one platform an advantage over the other.
Again, it doesn't really matter if they've optimized bits for either platform. I, as a user, just want the fastest platform.
Adobe however are wrong to show such indifference to their users of either platform and it's highly annoying. If they didn't have such a stranglehold on the 'photoshop' market then they'd not get away with that attitude and someone would come in with a fully optimized package. It's happened before - see Apple and FinalCut v Premiere. Or for that matter, Bibble and their RAW tools.
Originally posted by aegisdesign
Again, it doesn't really matter if they've optimized bits for either platform. I, as a user, just want the fastest platform.
Adobe however are wrong to show such indifference to their users of either platform and it's highly annoying. If they didn't have such a stranglehold on the 'photoshop' market then they'd not get away with that attitude and someone would come in with a fully optimized package. It's happened before - see Apple and FinalCut v Premiere. Or for that matter, Bibble and their RAW tools.
It's not going to happen. Apple would have to want to compete, and they can't. Bibble is a *very* small software house. The major ones have to think differently.
I'm with you. I wish they would do this. I, and others, have argued with Adobe about this, but they believe that it would damage their business.
I'd like to talk more, but I'm out of time for now.
Originally posted by aegisdesign
I disagree.
I have a perfect real world test there. I want to use iTunes - which platform runs it quickest? That is all that is important there, not which compiler I could recompile it under if I had the source (I don't) or which alternative program is faster (irrelevant to the test). The test is "I want the fastest machine to run my program".
Aegis,
It would be interesting to see the difference between iTunes mp3 and aac encoding on both platforms. I remember when aac first became available on the mac, my encode times suffered (in comparison to when I was ripping into mp3). Perhaps Windows machines are only relatively slow with aac encoding (which I've read gains a big boost from altivec) and less so with mp3?
Originally posted by chromos
Aegis,
It would be interesting to see the difference between iTunes mp3 and aac encoding on both platforms. I remember when aac first became available on the mac, my encode times suffered (in comparison to when I was ripping into mp3). Perhaps Windows machines are only relatively slow with aac encoding (which I've read gains a big boost from altivec) and less so with mp3?
Any time an encoding/decoding algorithm encodes/decodes for a smaller file or a higher quality file, it's going to take more computing resourses.
H.264 takes about four times as much computing power than does MPEG 2 for the same file. But it produces a significantly smaller result, with better quality.
I've seen the same thing with PS. Adobe would come out with new or better filters, only to abandon them at the time because computers weren't up to it yet
MP3 is pretty simple, and not very good. It was invented when computers were a fraction as powerful as they are now.
Even now, very few personal computers can decode 1080p H.264. Three years ago there weren't any in the home that could. In two years time all will.
either way if apple plans to play hd on these new laptops they better come with a onboard chip for this (hopefully in way of new video cards) Apple is netorious for shipping cards with nice onboard hardware features and not taking advantage of them in laptops.
Originally posted by melgross
Any time an encoding/decoding algorithm encodes/decodes for a smaller file or a higher quality file, it's going to take more computing resourses.
H.264 takes about four times as much computing power than does MPEG 2 for the same file. But it produces a significantly smaller result, with better quality.
I've seen the same thing with PS. Adobe would come out with new or better filters, only to abandon them at the time because computers weren't up to it yet
MP3 is pretty simple, and not very good. It was invented when computers were a fraction as powerful as they are now.
Even now, very few personal computers can decode 1080p H.264. Three years ago there weren't any in the home that could. In two years time all will.