Audible sound distortions if the key lock was turned on. Engine 3.0.0

The problem happens in ENGINE DJ the computer version too

1 Like

here is another example in engine dj for pc Engine DJ 2023 03 12 19 52 09 - YouTube

1 Like

Keylock does not bypass at zero pitch on these. With Elastique activated, it does do something at zero pitch. It causes a slight increase in the pre-existing roll-off, IMD aliasing echo, and ultrasonic noise otherwise already present with Elastique off in the wildly sample rate converted and aggressively processed Prime player firmware. It’s a subtle effect either way usually, though, that’s most audible on very dense, less dynamic tracks. Think lossless files sounding like MP3s: YMMV.

I did document two issues with keylock playing test signals that were overt with scope traces. One was a persistent oscillation of test waveform amplitude, maybe related to the IMD. There was another issue with test signals where they would randomly become mutilated after pitching extreme negative amounts, and would only trace properly again regardless of pitch after keylock was toggled off and then on again. I couldn’t find evidence either was occurring with actual music, though.

It seems like some Prime models’ 3.0 firmware have a different, overt sonic glitch, though, to any of the above, but, then again, maybe it’s related. I haven’t noticed your specific problem yet on the SC5000M, but my hearing also isn’t what it used to be.

1 Like

I’ve just reproduced the same issue with that track in Engine DJ Desktop (Mac)

Out of interest, how come your track is in 6A (G Min) in Engine DJ when the track is actually 9B (G Maj) - Is that what Engine DJ analysed it as? Mine analysed as 9B.

1 Like

I always analyze tracks before adding to the library using Mix in Key

1 Like

Moin @BennyTee,

phps. may the following link help you a little bit for understandig the differenc between 6A <—>9B

https://community.enginedj.com/t/prime-4-key-in-library-view-is-different-than-performance-view/43273

I myself learnt it when digitizing my Vinyls. I had not adjusted the pitch / speed properly (not 0) at my 1210 turntables. When I recognized this and improved by a second attempt the key differs between my first attempt.

So I assume that your downloaded track may have in the original another speed than in the example discussed here in the post.

Only an assuption from my side to check this point.

Good luck

Brgds BeatMaster

1 Like

Yeah it would make sense that differing pitched versions of the same track would/could result in differing key’s when analysed. However in this instance I would just put it down to that fact that the track was analysed using different software. I think if I was to analyse the track using Mixed in Key it would give the same results as mrtime G(min). Beatport have the track down as G(maj) which is what Engine DJ analysed it as. I’m not going to pretend I could tell the difference, it was merely an observation when trying to reproduce mrtime’s test. Ultimately it wasn’t a factor in reproducing the issue because I got the same results regardless.

2 Likes

I think you guys who are having problems should run a fast Fourier transform spectrum analysis in like Sound Forge using some test tones or volume-normalized noise, and then look at where the extra peaks are showing up. Granted, the following is with keylock off, but this is Traktor vs the usual Engine OS performance you can use as a reference:

1 Like

I got some weird results using RMAA. The pitch was at 0, the test signal was 44100 at 16 bits.

1 Like

Weird. Like the filter is completely wrong. Distortion harmonics are way up. What about IMD+Noise? That’s the one that’s usually 100X the reference. Also make sure your sample rates are working correctly. Run the original test track through RMAA so you have that in comparison to what you’re comparing it to. Like so:

image

This is for 2.4

1 Like

Good job. Wow. IMD+noise has increased 23%, response definitely seems way out of whack, even compared to normal excessive roll off. I would definitely do a bug report using this, but you might want to do a pass through just with the mixer also as a reference to further bolster your claim the sample rates are correct. Your numbers for keylock off and the old firmware confirm to me that your methods are kosher, though.

BTW, where are the bug reports going now for the public release firmwares? I just found a bug in 3.0.0.

1 Like

I’m having sound issues on my prime 2

2 Likes

InMusic is apparently tracking this thread/bug already. So, probably no point in doing another bug report unless they ask for one.

1 Like

Maybe they should pay you both as audio engineers as they, apparently, don’t have any on the payroll.

2 Likes

Weirder results… Test signal 96 kHz 24-bit. The player is connected directly to the RME ADI-2 via SPDIF.

v3.0.0

v2.4.0

They now had Luis Serrano Cavero from Kontrol DJ and ImageLine the last I knew with the Gibson acquisition. He designed some of my favorite old stuff. I’m not sure what they’ve got him working on, though, if he’s still with InMusic.

Make sure you also do a loop through not just in-situ within RMAA (the listed test signal in the numeric results) but either through and back into the RME or, better yet, from the mixer and into the RME.

While the frequency response in the audible range is much worse, which was obviously ridiculous to begin with for 96khz, and there’s still both IMD with keylock on at zero pitch and appalling THD during the sine sweep, that’s much less ultrasonic noise of late on both firmwares for some reason. I wonder if they’ve been altering the sound processing without telling us. They’d previously said they would only release changes to the core Prime DSP playback fidelity after saying so, that way we could listen and test for the changes. I get accidents, but there looks to have been secret changes already in 2.4 if I’m not mistaken. Or perhaps we’re just seeing the effects of newer hardware builds with much less jitter? PWM power supply noise certainly wouldn’t cause ultrasonic noise on SPDIF data.

RMAA is not perfect, though, so that’s why I’m talking about trying loop backs through gear of known performance like the mixer and RME interface itself.

1 Like

I tried to record the signal in the same mode in which the player’s digital output works and so that the mixer’s DSP does not affect the result. In this case, I trust the RME device more than the mixer. But I will try to use the mixer as an interface. Perhaps the result was affected by the SteadyClock FS (lowest jitter and highest jitter immunity) that RME use

I don’t mean the mixer as the USB record interface being fed the players that are running the test signal, though you could do that for the heck of it. The mixer USB in to USB out for RMAA tests pretty great, though obviously not perfect. HiFi that I could tell, though.

I meant the computer running test signal → mixer playing from the USB → mixer SPDIF out → into RME SPDIF in, as if the mixer was the playback device if possible. Unless you’ve got some other SPDIF-equipped playback device you can compare the SC Prime players to. It should test great with the mixer as the player, but not as perfect as the raw in-situ test signal inside RMAA that you’ve already done. At the very least, out the RME SPDIF and back into its own SPDIF in like I’ve done on my Tascam to ensure I get similar results as the in-situ raw test signal evaluated by RMAA directly.

Oh you might also want to try TruRTA and some test waveforms: impulse, square, saw, etc, though if you just record the tests in a wave editor you can look at them directly that way, too, afterwards.

Yes, i have x1850, i also have Tascam dr-680 mk2 with digital I/O

1 Like