Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3 Listening Test at 128 kbps (Read 207003 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.

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 #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 #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.



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.

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 #336
You have to be a HA oldtimer to know that  But he posted pretty publically on this forum in the past.

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?

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.

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.

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.

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 #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  )

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.

 

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.

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)

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.