Media Encoding Performance using DVD Shrink, WME9, Quicktime and iTunes

First up is DVD Shrink 3.2.0.15. Our test was simple - we took a copy of Star Wars Episode VI and ripped the full DVD to the hard drive without compression, effectively giving us an exact copy of the disc on the hard drive.  Then, using the copy of the DVD on the hard drive (to eliminate any DVD drive bottlenecks), we performed a DVD shrink operation to shrink the movie to fit on a single 4.5GB DVD disc.  All of the options were left on their defaults, so the test ends up being pretty easy to run and reproduce.  The scores reported are DVD encoding times in minutes, with lower numbers meaning better performance. 

The DVD Shrink test is quite important as DVD Shrink is quite possibly one of the easiest tools to rip a DVD.  The easier a tool is to use, the more likely it's going to be used, and arguably, the more important performance using it happens to be. 

DVD Shrink 3.2.0.15

MPEG-2 encoding performance using DVD Shrink clearly favors the Pentium Extreme Edition; while the Athlon 64 X2 4800+ is competitive, it falls behind both EE chips.

Moving on, we have our Windows Media Encoder 9 test, which uses the advanced profile settings for video encoding.  We left all settings at their defaults and just proceeded with an MPEG-2 to WMV-HD conversion.  The values reported are in frames per second, with higher numbers being better.

Windows Media Encoder 9 - Advanced Profile

The situation under Windows Media Encoder 9 is no different, with the EE taking the lead once more.

Next up, we have Quicktime Pro 7.0.3 and we perform a MPEG-2 to H.264 encoding task.  All of the settings are left at their defaults, with the exception that we optimize the output file for download with a 256kbps data rate while leaving the resolution untouched.  We also adjust the video options to optimize for the best quality.  We report the transcoding time in minutes, with lower values being better. 

H.264 Encoding with Quicktime Pro 7.0.3

The tables are turned under Quicktime 7, with the Athlon 64 X2s taking the lead and pushing the Pentium EE 955 to third place.

Finally, we have a MP3 encoding test using iTunes 6.0.1.3.  For this test, we simply took a 304MB wav file and converted it to a 192kbps MP3 file, measuring the encode time in seconds.  The only iTunes option that we changed was to prevent the playback of the song while encoding. 

MP3 Encoding with iTunes 6.0.1.3

MP3 encoding performance is a close race between the Athlon 64 X2 4800+ and the EE 955, with AMD taking the slight lead.

3D Rendering Performance using 3dsmax 7 Gaming Performance
Comments Locked

84 Comments

View All Comments

  • Anand Lal Shimpi - Friday, December 30, 2005 - link

    I had some serious power/overclocking issues with the pre-production board Intel sent for this review. I could overclock the chip and the frequency would go up, but the performance would go down significantly - and the chip wasn't throttling. Intel has a new board on the way to me now, and I'm hoping to be able to do a quick overclocking and power consumption piece before I leave for CES next week.

    Take care,
    Anand
  • Betwon - Friday, December 30, 2005 - link

    quote:


    We tested four different scenarios:

    1. A virus scan + MP3 encode
    2. The first scenario + a Windows Media encode
    3. The second scenario + unzipping files, and
    4. The third scenario + our Splinter Cell: CT benchmark.

    The graph below compares the total time in seconds for all of the timed tasks (everything but Splinter Cell) to complete during the tests:

    AMD Athlon 64 X2 4800+ AVG LAME WME ZIP Total
    AVG + LAME 22.9s 13.8s 36.7s
    AVG + LAME + WME 35.5s 24.9s 29.5s 90.0s
    AVG + LAME + WME + ZIP 41.6s 38.2s 40.9s 56.6s 177.3s
    AVG + LAME + WME + ZIP + SCCT 42.8s 42.2s 46.6s 65.9s 197.5s

    Intel Pentium EE 955 (no HT) AVG LAME WME ZIP Total
    AVG + LAME 24.8s 13.7s 38.5s
    AVG + LAME + WME 39.2s 22.5s 32.0s 93.7s
    AVG + LAME + WME + ZIP 47.1s 37.3s 45.0s 62.0s 191.4s
    AVG + LAME + WME + ZIP + SCCT 40.3s 47.7s 58.6s 83.3s 229.9s


    We find that it isn't scientific. Anandtech is wrong.
    You should give the end time of the last completed task, but not the sum of each task's time.

    For expamle: task1 and task2 work at the same time

    System A only spend 51s to complete the task1 and task2.
    task1 -- 50s
    task2 -- 51s

    System B spend 61s to complete the task1 and task2.
    task1 -- 20s
    task2 -- 61s

    It is correct: System A(51s) is faster than System B(61s)
    It is wrong: System A(51s+50s=101s) is slower than System B(20s+61s=81s)
  • tygrus - Tuesday, January 3, 2006 - link

    The problem is they don't all finish at the same time and the ambiguous work of a FPS task running.

    You could start them all and measure the time taken for all tasks to finish. That's a workload but it can be susceptible to the slowest task being limited by its single thread performance (once all other tasks are finished, SMP underutilised).

    Another way is for tasks that take longer and run at a measurable and consistent speed.
    Is it possible to:
    * loop the tests with a big enough working set (that insures repeatable runs);
    * Determine average speed of each sub-test (or runs per hour) while other tasks are running and being monitored;
    * Specify a workload based on how many runs, MB, Frames etc. processed by each;
    * Calculate the equivalent time to do a theoretical workload (be careful of the method).

    Sub-tasks time/speed can be compared to when they were run by themselves (single thread, single active task). This is complicated by HyperThreading and also multi-threaded apps under test. You can work out the efficiency/scaling of running multiple tasks versus one task at a time.

    You could probably rejig the process priorities to get better 'Splinter Cell' performance.
  • Viditor - Saturday, December 31, 2005 - link

    Scoring needs to be done on a focused window...
    By doing multiple runs with all of the programs running simultaneously, it's possible to extract a speed value for each of the programs in turn, under those conditions. The cumulative number isn't representative of how long it actually took, but it's more of a "score" on the performance under a given set of conditions.
  • Betwon - Saturday, December 31, 2005 - link

    NO! It is the time(spend time) ,not the speed value.
    You see:
    24.8s + 13.7s = 38.5s
    42.8s + 42.2s + 46.6s + 65.9s = 197.5s

    Anandtech's way is wrong.
  • Viditor - Saturday, December 31, 2005 - link

    quote:

    It is the time(spend time), not the speed value

    It's a score value...whether it's stated in time or even an arbitrary number scale matters very little. The values are still justified...
  • Betwon - Saturday, December 31, 2005 - link

    You don't know how to test.
    But you still say it correct.

    We all need the explains from anandtech.
  • Viditor - Saturday, December 31, 2005 - link

    quote:

    You don't know how to test


    Then I better get rid of these pesky Diplomas, eh?
    I'll go tear them up right now...:)
  • Betwon - Saturday, December 31, 2005 - link

    I mean: You don't know how the anandtech go on the tests.
    The way of test.
    What is the data.

    We only need the explain from anandtech, but not from your guess.

    Because you do not know it!
    you are not anandtech!
  • Viditor - Saturday, December 31, 2005 - link

    Thank you for the clarification (does anyone have any sticky tape I could borrow? :)
    What we do know is:
    1. All of the tests were started simultaneously..."To find out, we put together a couple of multitasking scenarios aided by a tool that Intel provided us to help all of the applications start at the exact same time"
    2. The 2 ways to measure are: finding out individual times in a multitasking environment (what I think they have done), or producing a batch job (which is what I think you're asking for) and getting a completion time.

    Personally, I think that the former gives us far more usefull information...
    However, neither scenario is more scientifically correct than the other.

Log in

Don't have an account? Sign up now