Skip to main content

Topic: MP3 Listening Test at 128 kbps (Read 163334 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
MP3 Listening Test at 128 kbps
Reply #325
Thank you for your findings lvqcl.

Do you guys think I should wait x days for Apple to respond to my mail or should I continue with the test right away? I have a singlecore Celeron notebook, so it wouldn't be a problem to encode the samples and start the test.
  • Last Edit: 06 October, 2008, 02:38:37 AM by Sebastian Mares

  • singaiya
  • [*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #326
It's one thing that you have a single core machine to make the encodes, but many people don't have a single core computer. So, in the event that iTunes makes a strong showing in the results, and therefore people are more comfortable using it, they won't get the same performance from *their* encodes. The iTunes contender samples would not be representative of real world use.

Of course, it may be that Apple fixes the problem, but I wouldn't hold my breath.

MP3 Listening Test at 128 kbps
Reply #327
Of course, I would include a big "WARNING" or something like that on the listening test page.

  • singaiya
  • [*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #328
I still think it should be disqualified. These tests are time consuming and require a lot of unbroken concentration. I was planning on participating but I don't think I will if this broken encoder is included.

Seriously, what is the point in having a rank on a contender when its samples can only be produced on single core machines?

MP3 Listening Test at 128 kbps
Reply #329
I could also do the same thing I did with the Nero AAC encoder after Guru noticed the bug with the bitrate allocation, although that was a slightly different story.

  • Alex B
  • [*][*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #330
It would be good if Apple would acknowledge that the encoder has a problem with multi-core machines and that the encoder behaves as intended on a single-core machine. Then we could assume that Apple will eventually fix the problem and the test results would be usable for all iTunes users.

BTW, has anyone tried what happens when the machine has more than two cores?

As Sebastian have said, in general it would be very interesting to have up-to-date test results of the iTunes MP3 encoder. It is probably the dominant MP3 encoder on Macs and many professional content creators work on Macs.

EDIT

After finding out that iTunes isn't faster than LAME I was against testing it because I didn't see the usefulness of the results in a wider perspective beyond my personal needs, but I have changed my mind.
  • Last Edit: 07 October, 2008, 07:06:15 AM by Alex B

MP3 Listening Test at 128 kbps
Reply #331
I could test on a 8 core machine... (4 real, 4 synthetical cores)

MP3 Listening Test at 128 kbps
Reply #332
Just did a quick test and encoded at 112 and 128 kbps. The results are just like with two cores. 112 kbps file comes out at 122 kbps, 128 kbps file comes out at 141 kbps.

MP3 Listening Test at 128 kbps
Reply #333
I am trying to get in touch with someone from Apple directly. If I don't get any feedback soon or if the fix is supposed to come in a version that will be released too late (let's say in a month or so), I guess the best thing I can do is to 1. display a big warning on the presentation page and 2. display the iTunes ranking detached from the rest like I did for Nero. As Alex B pointed out, iTunes is a really popular MP3 encoder at least on Macs and I would like to avoid disqualifying it entirely.

  • Alex B
  • [*][*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #334
Could the mysterious Apple developer mentioned in the following quote help contacting the right person(s) at Apple?

It's one person (that I know of) that is member of this forum. But I suspect he's not alone working on the AAC encoder...

... I bullied him already :B

... He said he wouldn't mind including it in the encoder, but it doesn't depend only on him. It also depends on the QuickTime division, the iTunes division, the iPod division... For that reason, it'll probably only happen when a decision comes from above.

I have no idea who this person could be.

MP3 Listening Test at 128 kbps
Reply #335
I have no idea who this person could be.


I do...

  • menno
  • [*][*][*][*][*]
  • Developer (Donating)
MP3 Listening Test at 128 kbps
Reply #336
You have to be a HA oldtimer to know that  But he posted pretty publically on this forum in the past.

  • Alex B
  • [*][*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #337
Does anyone have an idea of what Apple could have done wrong to cause an unlikely problem like this? 

Could Apple actually have included two separate MP3 encoder components and made a mistake when configuring the internal options?

If we would need to "reverse engineer" the situation, what would a developer use for intentionally making the encoder behave differently on different machines?

  • robert
  • [*][*][*][*][*]
  • Developer
MP3 Listening Test at 128 kbps
Reply #338
Some digging: http://developer.apple.com/quicktime/whatsnew.htm

- "Multiprocessor (MP) Support" was added to QuickTime version 5
- "VBR Sound Compression Support" was added in QuickTime version 6

It's bad, that there seems to be no way to control the MP feature in QuickTime.

  • vlada
  • [*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #339
Alex B
I think the answer is quite simple. If you want to use full power of a multicore CPU, then you need to split the computing into more threads. This means you have to significantly change your algorithm.  I heard before that you will get different results with multithreaded versions of libavcodec, x264 or XviD codecs.

Multicore CPU is IMHO a very bad idea and direction. But CPU manufacturers had probably no other cheap solution on how to further increase power of their processors. If you want to use all cores at the same time in your encoder, you have to write it differently (much more complicated) compared to single thread encoder.

I hope this explains why you get different results on singlecore and multicore CPUs.

  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
MP3 Listening Test at 128 kbps
Reply #340
Multicore CPU is IMHO a very bad idea and direction. But CPU manufacturers had probably no other cheap solution on how to further increase power of their processors. If you want to use all cores at the same time in your encoder, you have to write it differently (much more complicated) compared to single thread encoder.

Multicore is not a bad idea. People normally have more than one program running. So each core can take care of each program.

Does anyone have an idea of what Apple could have done wrong to cause an unlikely problem like this?

Well, somewhere the split information processed on each core must be merged. You can have an issue there.

  • robert
  • [*][*][*][*][*]
  • Developer
MP3 Listening Test at 128 kbps
Reply #341
By the way, are CBR results binary identical on single and multi core machines? Do they have a problem there too?

MP3 Listening Test at 128 kbps
Reply #342
[...]
I encoded one album (~1 hour long) with MP3 CBR 160 kbps:
1 core:  3m 20s (= 200s)
2 cores:  1m 57s (= 117s)

The files have different comment tag, but identical audio content. With VBR, this isn't so:
[...]

MP3 Listening Test at 128 kbps
Reply #343
Just wanted to let you know that someone from Apple is investigating this.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
MP3 Listening Test at 128 kbps
Reply #344
Some digging: http://developer.apple.com/quicktime/whatsnew.htm

- "Multiprocessor (MP) Support" was added to QuickTime version 5
- "VBR Sound Compression Support" was added in QuickTime version 6

It's bad, that there seems to be no way to control the MP feature in QuickTime.

Let me quote myself:

Code: [Select]
                   1 core    2 cores
iTunes 4.9.0.17       135        137
iTunes 5.0.1.4        194        119

iTunes 4.9.0.17 uses QuickTime 6.5.2 and iTunes 5.0.1.4 uses QT 7.0.2. So I doubt that this particular bug was introduced in QT 5 or 6.

I also tried to install iTunes 4.9 and then upgrade QT to 7.5. But this didn't affect MP3 coder at all: mp3 files created before and after upgrade were bit-identical. (AAC encoding was changed, however: when encoding to AAC, iTunes crashes  )

  • nao
  • [*][*]
MP3 Listening Test at 128 kbps
Reply #345
Probably iTunes mp3 encoder doesn't depend on QuickTime, because QT API has no interface to produce mp3.

MP3 Listening Test at 128 kbps
Reply #346
Good news! I just received a mail from one of the persons in charge and the bug was indeed identified and should be fixed in the next iTunes version. Thanks to the Apple developers for reacting so quickly and also thanks to the HA members who supported in identifying the problem.

Edit: BTW, it seems that in some cases, CBR encoding can be affected by this bug as well.
  • Last Edit: 07 October, 2008, 04:08:15 PM by Sebastian Mares

  • Alex B
  • [*][*][*][*][*]
MP3 Listening Test at 128 kbps
Reply #347
Did that person say anything about which behavior is correct? I wouldn't be surprised if they would consider the single-core version broken and limit the amount of the bitrate variation.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
MP3 Listening Test at 128 kbps
Reply #348
BTW, I'd like to see bitrates of all 14 test samples when they encoded with iTunes on single-core CPU (just out of curiosity)

  • menno
  • [*][*][*][*][*]
  • Developer (Donating)
MP3 Listening Test at 128 kbps
Reply #349
Did that person say anything about which behavior is correct? I wouldn't be surprised if they would consider the single-core version broken and limit the amount of the bitrate variation.


Single core behavior is correct.