MPC5000 timing in numbers

Hi,

I´ve recently purchased a new MPC5000 and finding contradictory comments in the net about its timing, I´ve decided to make some measurements of it with some patiente.

I´ve recorded a sequence of several bars of heavily quantized 16th notes (no swing at all), using one internal sound.
I´ve then recorded the output to my computer and using a sound editor program I´ve measured the separation between sounds in samples. In theory this separation should be a constant value (or near constant) in order to have a good timming.
I want to note that I´ve obtained identical results sampling the sequence inside the MPC (using "Main Out" option in Sample Rec Mode) and doing the measurement in Trim Mode; yes, I took the time to do it.
As a reference I used a 120bpm tempo, but as commented later, similar results are obtained at different tempos.
Is important to note too that I´ve done the measurements using OS version 2.0 first and then version 1.01, in both Pattern Mode and Song Mode obtaining absolutely equal results.

So these are the results (in samples): 5504 5504 5504 5504 5504 5504 5568 5504 5504 5504 5504 5504 5504 5504 5504 5568 5504 5504 5504 5504 5504 5504 5504 5568 5504 5504 5504 5568 5440 5568 5440 5568 5504 5568 5440 5568 5504 and so on...

So far so good. It looks like the MPC5000 has rock solid timming except some occasional retard or advance of 64 samples respect the 5504 value every now and then, that is aproximately 1,5 miliseconds at 44,1 Khz recording. Let´s take 5504 samples as a reference value.

But imperfection arises as you add more sounds to the sequence. I´ve used now two identical internal sounds one hard panned to the left (Track 1) and the other to the right (Track 2), and added a second 16th heavily quantized line to the sequence.
It doesn´t matter if you use the same track of the first sound or a new one because the results are identical. Steps with a value equal to the refence one, that is 5504 samples, are represented by a hyphen.

Step..........................Track 1.........................................Track 2

1................................5504...........................................5504
- - - - -
8................................5568 (+64)..................................5568 (+64)
- - - - -
15..............................5568 (+64)...................................5568 (+64)
- - - - -
23..............................5568 (+64)...................................5568 (+64)
- - - - -
31..............................5568 (+64)...................................5568 (+64)
- - - - -
39..............................5568 (+64)...................................5568 (+64)
- - - - -
46..............................5504............................................5568 (+64)
47..............................5568 (+64)...................................5568 (+64)
- - - - -
51..............................5504............................................5568 (+64)
- - - - -
53..............................5504............................................5568 (+64)
and so on...

Analizing these values we find that besides both tracks retard 64 samples from the reference value in some cases, in others the second track retards in 64 samples respect the first track.
As a result the sound bounces to the left every now and then, almost in a cyclic manner.

Then I added a third track using the same internal sound and panning it to the right again, but routing track number 2 to an individual output so I could mute it in an outside desktop mixer, and record only track 1 and track 3 in order to measure the gap between them.
Again steps with a value of 5504 are represented with a hyphen.

Step.......................Track 1............................Track 3
1.............................5504................................5568 (+64)
2.............................5568 (+64).......................5568 (+64)
- - - - -
6.............................5504................................5568 (+64)
7.............................5568 (+64).......................5568 (+64)
8.............................5540 (-64)........................5504
9.............................5568 (+64).......................5568 (+64)
- - - - -
13...........................5504.................................5568 (+64)
14...........................5504.................................5568 (+64)
15...........................5568 (+64)........................5568 (+64)
- - - - -
19...........................5504..................................5568 (+64)
20...........................5504..................................5504
and so on...

We find the same behaviour of the tracks as before, but now track 3 retards in 64 samples respect track 1 more frequently than before and the sound bounces often to the left.

I've added a fourth track muting tracks 2 and 3. I won't put more sample values, just note that as more tracks are added the sound bounces to the left more and more frequently, and with 5 tracks running it does it almost continuosly, meaning that the timming suffers more and more as long as you keep adding tracks.

I think that's the reason why people find old MPCs like the MPC3000 and MPC60 to have better timing than the MPC5000. Sadly I don't own any of these machines to make some measurements with them, but there is enough information in the net that reflects these old MPCs have better figures than the 5000.
I just compared the MPC5000 with software programs that have sample accurate timing, and although I couldn't say the Akai has a bad timing the difference between them is still audible, being software programs more tight and solid.

As commented earlier, I made some measurements at different tempos (between 100bpm and 135bpm) and what amazes me is that the gap between tracks is a constant value of 64 samples independently of the tempo choosed. It seems that there is some kind of routine in the MPC operating system that obstruct it to have a sample accurate timing.
So I think that this is a missed opportunity by Akai because if they are able to correct this defficiency in a future OS update, they could present the MPC5000 as the tightest timing hardware sequencer sampler in history, improving the performance of old MPCs and would have nothing to envy to software programs in that department.

What do your ears tell you?

Congratulations, you've dicovered the world of physical MIDI jitter

Not sure about the 64 samples drift, but you'd have similar results with any of the former MPC's or any other hardware (not virtual) MIDI sequencer. Physical MIDI is a serial protocol, not a virtually parallel protocol as it can be realized in software hosts.

See this recent thread: viewtopic.php?f=5&t=142548&start=15

MIDI jitter?

I've stated clearly that I've used internal sounds in the measurements.

MIDI is a serial protocol as long as you interconnect two different machines.

morboturbo wrote:MIDI jitter?

I've stated clearly that I've used internal sounds in the measurements.

MIDI is a serial protocol as long as you interconnect two different machines.

Yes, MIDI jitter. Have you read the other thread? Any MPC or similar hardware sampler, whether it is sequenced by another sequencer or sequences itself seems to be bound to the laws of physics.. the laws of physical MIDI which is serial to be exact.

Any software DAW has it's way of internally sending MIDI parallel to virtual instruments.

If you think that the MPC5000 executes internal MIDI notes serially, how can you explain the fact that in my measurements there are many steps with two or three tracks running simultaneously that sound with sample accurate timing, while in others there is that drift of 64 samples?

MIDI notes or other MIDI information is sent serially by MIDI connectors because MIDI communication protocol is serial, but it doesn't have to be that way when the MPC or any other sequencer plays internal sounds.

Good questions
hm, maybe they tried to implement a systems where it works parallel on seperate tracks, but there still seems to be kind of a jitter... your figures show exactly that. I always thought that "the jitter" that can be heard the most when two snare drums are layered (varying phasing/comb filtering) stems from the fact the MP's are bound to physical MIDI laws. And also note that "the jitter" keeps getting worse the more stuff is layered.

And why it's always 64 samples ? At 120 BPM and 44.1kHz sample rate 3 ticks (3/960th of a quarter note) would be 68,90625 (=69) samples.
Are you perhaps MIDI syncing the 5K with the DAW where the DAW side is the master.. that's the only thing I can guess is maybe the reason for a fix value jitter that isn't a multiple of 1/960th of a quarter note.

Sorry I didn't mention in the post I did the measurements using internal clock with no other machine connected to the MPC5000 via MIDI.

Its interesting your suggestion of 3 ticks of retard at 120bpm, but the drift of 64 samples is a constant value independently of the tempo choosed between a wide range I used for the measurements. If the jitter had something to do with ticks, the drift would be a different value at different tempos.

Another thing I noticed:
Even the first (border to the 2nd) step 5504 is a multiple of 64. At 120 BPM this must have been 5512.5 samples (5512 or 5513).
Why is each recorded step exactly a multiple of 64 samples? As if the smallest resolution is 64 sample irrespective of the tempo and the PPQN resolution.
Could you do the test again with for example 117 BPM... I wouldn't wonder if the 16th steps would be 5632 samples and sometimes 5696 from each other instead of the correct value 5653 or 5654.

Hi otobot,

I'm living very busy days lately, but I hope tomorrow night I could give you detailed information about my test at different tempos, including 117bpm.

May be you've got the key to the problem when you realized that step reference values are multiple of 64. I've analized my data and found surprising conclusions...

I'll keep you informed.

If this doesn't translate into anything audible and you can't do anything about it anyway ...at the end of the day what's the point outside of sounding more geeky than the average user?


Honest question no hate.

I think the point is that some people can effectively hear this timing deviation. Or better said: some people will feel it, since the variation is very very slight, but e.g. if you're doing some electro-type, heavy on the 16th notes stuff, you can feel the difference in timing (for honesty's sake: I never noticed this audibly --> my old old old PC running Cubase was so bad in timing that my MPC 5k is a step up for me in this area.

Correct me if I'm wrong, but if eventual delays are always 64 samples long, the relative error becomes bigger as the tempo increases. I'm going to try and see if I can hear these delays at Drum & Bass type tempos (p.s. to preempt any comments, recording at 'half signature' and doubling up the speed will not fix this, since the delay will still be 64 samples at 44.1kHz.)

I'm ready for these surprising conclusions!

p.s. Are you sure, since it's always in multiples of 64, that there's not something to do with buffer size in capturing or playing sound? I mean like the MPC engine 'spits out' it's data in chunks of 64 samples, or maybe the capturing engine does it like this? No wait, that last part doesn't make too much sense I guess..

Thanks for the research!

DL

First of all, my intention with this post is to try to put objectivelly into numbers what subjectivelly is reflected in user comments about the timing of the MPC5000.
At least what I read, there is a general assent that older MPCs (MPC3000 and MPC60) have better timing than the MPC5000.

I've said earlier that comparing a sequence executed by the MPC5000 and a software program with sample accurate timing I feel the later more tight, especially when running several hard quantized tracks.

I know it's difficult, but the final point would be that Akai would release a new OS for the MPC5000 with sample accurate timing if the machine is capable to do it. If they do it they will have the best timing MPC ever.

Now I will expose some new data and some conclusions that I think are relevant.

otobot asked me to measure a sequence at 117bpm. I will expose two more measurements.


One track Sequence at 117bpm. 16th note heavily quantized as ever.

Ideal separation between sounds in samples (at 44.1kHz recording): 5653,85

Closest multiple of 64: 5632 (that is aprox. 22 samples less than ideal)

Step values: 5632 5632 5696(+64) 5632 5632 5632 5696(+64) 5632 5632 5696(+64) 5632 5696(+64) 5632 5632 5696(+64) 5632 ...

It's clear that every now and then there is the delay of 64 samples as before, and all step values are multiple of 64 (thanks otobot).


One track Sequence at 125bpm. 16th note heavily quantized as ever.

Ideal separation between sounds in samples: 5292

Closest multiple of 64: 5312 (that is 20 samples more than ideal)

Step values: 5312 5312 5248(-64) 5312 5312 5248(-64) 5312 5312 5312 5248(-64) 5312 5248(-64) 5312 5312 5312 5248(-64)

All steps again are multiple of 64 but now some of them are moved forward 64 samples.

So there is a compensation of the situation of some steps in order to as a whole they would be separated by the ideal sample number.
Has this something to do with the Hard Disk Recording facility? May be. But anyway and even if the MPC5000 only executes notes in increments of 64 samples, I think that the MPC5000 is perfectly capable of performing at sample accurate timing even executing several hard quantized tracks, if there wasn't that compensation of 64 samples.

Now the surprise...

This is the final measurement.

A sequence of two tracks of 16th notes at 120bpm.

Track 1 quantized as ever. Track 2 quantized but delayed just one tick (1/960 of a quarter note) respect Track 1.

At 120bpm 1 tick (1/960 of a quarter note) corresponds to aproximatedly to 23 samples.

Closest multiple of 64 respect ideal separation between notes: 5504

Values

Step...........Track 1.................Track 2 (+1 tick)
1...............5440(-64)................5504
2...............5568(+64)...............5568(+64)
3...............5440(-64)................5504
4...............5568(+64)...............5568(+64)
5...............5504........................5504
6...............5504........................5568(+64)
7...............5504........................5568(+64)
8...............5568(+64)................5568(+64)
9...............5504.......................5504
10..............5504......................5504
11..............5504......................5504
12..............5504......................5504
13..............5504......................5504
14..............5504......................5568(+64)
and so on...

Can you see any difference between this table and the one I presented with two heavily quantized tracks? They are very similar aren't they?
If the MPC5000 executes notes in increments of 64 samples then we need at least 3 ticks to hear (read) any difference at 120bpm.
So here is the surprising conclusion: the MPC5000 hasn't a resolution of 1/960 of quarter note, it has 3 times lesser this figure, at least in a very wide range of tempos.
Is this a bug? I think is a monumental one. Should this encourage Akai to correct this behaviour of the machine in a future OS update and implement it with sample accurate timing?
Well, you know by now my opinion.

Thanks for the tests, morboturbo. Very interesting results! I'll do some test tonight with my 5K and 500 too and report back.

That was alot of numbers to look over LOL.
Nice write up and researching.