All .m4a files with AAC at 48kHz have a bug where Engine plays them back slowly. It plays them as if they were at 44.1kHz, so they sound very slow. This happens both in the Mac software and on the Prime 2 standalone unit. I found that the workaround is unlocking the track analysis and then re-analyzing it. However, I have no way of doing this process for all the songs I have in this format
I have a screen recording with the issue but I can’t upload it here.
IMHO the bug isn’t Denon, it’s the DRM in the file. Where you getting your miusic from?
DRM usually encrypts files, not changes the playback sample rate from what I remember.
I wonder if @st.cool is onto something where on first import, Engine may be making assumptions?
You can sort by filetype 
I’m wondering why you say it’s playing them as if they’re 44.1. How would you determine that? I’ve recorded audio at 192k or 96k and then forced digital playback at 48k for sound design purposes. Are you sure of the source of your m4a files? Can anybody else confirm this with their m4a files? I can’t as I’m a few firmware versions back and playing from SC5000’s.
I’ve had a few 48 kHz tracks that played back slightly slower. This is not something I noticed only recently — I had already encountered it with the Prime 2 back then.
Since I honestly see no practical advantage for me in keeping 48 kHz files, all my purchases currently go through a resampler and are converted to 44.1 kHz. Problem solved.
If someone claims they can reliably hear the difference between 44.1 and 48 kHz in a typical DJ environment, they must have Spider-Man’s ears. 
It would be a different story if I were producing music or doing mastering. In that case, working at a higher sample rate can certainly have advantages and is certainly not a disadvantage.
That said, Engine OS should obviously be able to handle different sample rates properly.
Unfortunately, I don’t have the original examples anymore, but I’m quite sure that some of the files affected were M4As.
The main advantage of 48 kHz over 44.1 kHz is not about human hearing thresholds, but about digital audio processing and system alignment. The club sound system may be garbage, but the sound gets more garbagy if we feed garbage into the it. Check filter accuracy, anti-aliasing, happening inside our gear …
And yes, Spiderman and bats absolutely deserve high-fidelity too! But seriously, even though we can’t explicitly hear a 23 kHz tone, the filters used to cut off those frequencies can sometimes have a subtle phase smearing effect that bleeds down into the frequencies we actually can hear (like 15 kHz to 18 kHz, that is a range that makes a difference). Pushing the sample rate to 48 kHz pushes these aggressive brick-wall filters further out of the way, keeping the audible high-end, pristine, and airy … ah! Nice! 
This looks like a classic digital audio bug. You can verify it by calculating the change in speed … the audio stretches out in time. Specifically, it plays at about 91.8% of its original speed, pitch should also be lower. Is this the case? Since the problem specifically happens with AAC/M4A at 48 kHz, a bug in Engine’s handling of the AAC/M4A stream or its associated sample-rate metadata would certainly be plausible …
Possible solution: You can transcode the files to FLAC, keep the sample rate at 48 kHz and all the metadata. So far I have not had a problem with FLAC files on Denon DJ gear or in Engine DJ … transcoding to FLAC won’t improve the audio quality, since m4a with AAC is a lossy format, but you should be able to play them again.
I’d be curious if anybody else can recreate this anomaly with their gear. The OP also didn’t reference what version OS they’re using for their gear and what version of Engine they’re using.
No issues here with FLAC and WAV.
I agree with you on all of that — and, as we like to say sarcastically in Germany, we are getting into the territory of the “golden ears” here.
At home, on my high-end speakers — and believe me, they really are — I would claim that I could not reliably distinguish the same track at 44.1 kHz from 192 kHz in a blind test.
The situation is quite different at the SPL levels we typically have on a dancefloor. Terms like “airier” may work perfectly well when talking about B&W, T&A, Klipsch, etc., but on a dancefloor I don’t think that’s where the meaningful differences are.
I can’t demonstrate a meaningful difference there with measurements either, and in a blind test I’m pretty sure higher sample rates would not produce a reproducible perceptual difference.
with a PA and at dancefloor levels, this is not something I consider audibly relevant. Those higher sample rates can absolutely be useful or necessary at certain stages of signal processing, but at the end of the chain, I’m much less convinced they matter.
I’m simply more of a technical listener than a philosophical one. 
It has to hit, it has to be clear, and the bass has to be on point.
Time alignment — that matters. And that is absolutely audible.
I’m 100% sure they were always m4A files.
And every time I received one from someone else, it was m4A.
If I come across another one, I’ll ask if I can get a copy for “scientific purposes”.
Generated with Audacity, converted with FFmpeg, not tested yet:
440hz_48kHz.zip (168.5 KB)
You can, especially as a DJ, definitely hear the difference between a 44.1 kHz and a 192 kHz file, if you pitch down tracks by -50% with the key lock off.
A standard 44.1 kHz file is hard-limited at 22.05 kHz. There is absolute digital silence above that line, nothing at all. When you slow that file down by 50%, its absolute highest possible frequency drops to 11 kHz. And everything above 11 kHz becomes a complete black hole. This strips away the crisp transients of string bows, the breath of singers … Everything sounds heavily muffled, dark, … exactly like it is being played underwater, it is the underwater effect.
The Denon DJ SC6000 processes and outputs digital audio internally at a sampling rate of 96 kHz and 24-bit depth, I hope that is correct. The 192 kHz track was originally recorded with an ultra-wide frequency canvas, it captured a massive amount of acoustic energy all the way up to 96 kHz … even if the SC6000 caps it at 48 kHz.
When we slow the track down by 50%, all the rich overtones that are sitting way up in the bat zone between 20 kHz and 40 kHz are cut exactly in half. Now they land between 10 kHz and 20 kHz … this is the region responsible for air, sparkle, and brilliance in audio production. Even though the instruments are playing deep and low, the recording still feels alive and open because those shifted overtones are filling the top end … you can hear this.
This phenomenon is almost completely exclusive to acoustic music recorded in real spaces with physical instruments, like classical music. In the world of electronic music and synths this high-res time-stretching trick does not work, so no bat zone exploration with Techno, Trance, EDM … which is not available at 192 kHz quality most of the time anyway …
Back to the topic, I believe that @st.cool may have found a bug, where the Engine software or the OS does not correctly decode the content of an m4a container under certain conditions. I do not have any m4a test files, so I cannot confirm this … yet. I will see what I can do.
@uklotzde Thank you! This was exactly what I wanted to try next. Thank you so much! I have imported the file into Engine. I have analysed and played it in Engine DJ and recorded the output, and compared that with a 440 Hz reference tone - this clearly an A coming from Engine playback, it is not pitched down … it proves that the Engine DJ decoder can read 48 kHz AAC containers correctly (latest version of Engine DJ running at 48 kHz, Win 11 up to date). Why does it fail in certain cases?
There may be a mismatch between the info given by the m4a container and the actual content. You could check a file with the free tool MediaInfo, it can make the mismatch visible. You can find the software here:
Load a problematic file and select view - text. You should see something like this, which is from the test file of @uklotzde …
> General
> Complete name : C:\user\blah_blah_blah\440hz_48kHz\440hz_48kHz.m4a
> Format : MPEG-4
> Format profile : Apple audio with iTunes info
> Codec ID : M4A (M4A /isom/iso2)
> File size : 190 KiB
> Duration : 10 s 0 ms
> Overall bit rate mode : Variable
> Overall bit rate : 156 kb/s
> Writing application : Lavf62.12.102
>
> Audio
> ID : 1
> Format : AAC LC
> Format/Info : Advanced Audio Codec Low Complexity
> Codec ID : mp4a-40-2
> Duration : 10 s 0 ms
> Source duration : 10 s 21 ms
> Source_Duration_LastFrame : -5 ms
> Bit rate mode : Variable
> Bit rate : 153 kb/s
> Maximum bit rate : 256 kb/s
> Channel(s) : 1 channel
> Channel layout : M
> Sampling rate : 48.0 kHz
> Frame rate : 46.875 FPS (1024 SPF)
> Compression mode : Lossy
> Stream size : 187 KiB (98%)
> Source stream size : 188 KiB (99%)
> Default : Yes
> Alternate group : 1
This output has two sections, General and Audio. Do you see maybe two entries for Sampling rate, one in the upper General section and one in Audio? The test file was encoded with FFMpeg-4, it looks really nice and tidy … but other encoders may be different.
Don’t expect shady YouTube rips to be encoded with correct audio metadata. I have seen some bad examples.
This is easy enough to check:
Play the suspect AAC track on Engine and record at zero pitch, and then compare the two track lengths to each other.
You could also play a 1khz tone AAC 48khz sampling frequency test track on Engine, and then look at it on a spectrogram with FFT, like in Soundforge.
If you can demonstrate it, then write up a bug report for InMusic.
As for whether you can hear the difference in Engine’s DSP coding between 44.1 kHz and higher rates, you’re starting from a difficult position with this gear: even with both the theoretical and demonstrated benefits of moving integration filter artifacts out of the most sensitive range of human hearing at higher sample rates.
You do get very slightly more high-frequency extension at 48 kHz than at 44.1 kHz on Engine, and minor incremental gains at rates beyond that. However, the bandwidth gain relative to the sample rate increase is abnormally disproportional. Earlier versions of the Prime firmware didn’t manage even that, and certain higher rates actually degraded treble extension further. Later firmware updates appear to have worsened aliasing distortion, folding ultrasonic garbage generated by the DSP back down into the audible range.
We still don’t know conclusively what sample rate the Prime player separates run at internally. Vince stated 96 kHz, while a subsequent InMusic representative claimed all Prime gear, including the separates, operates at a common main work rate of 48 kHz. If the latter is true, the player separates are pointlessly upsampled to 96 kHz just prior to the DAC and S/PDIF output stages.
Testing suggests a 48 kHz internal work rate is more likely than 96 kHz based on the spectral placement of distortion artifacts. Yet, the usable bandwidth of a 44.1 kHz file played through Engine is more reminiscent of what you’d expect from a 32 kHz rate.
Alternatively, this could be a 48 kHz or 96 kHz DSP work rate utilizing a very relaxed anti-aliasing filter. While a relaxed filter offers time-domain benefits, such as minimizing post-ringing and preserving transient punch, it is poorly suited for suppressing ultrasonic content. This design choice is understandable if the pipeline uses low-tap, computationally efficient FIR filters to keep latency imperceptible; enforcing a steep cutoff on a low-tap filter introduces severe passband ripple and phase issues. In that context, opting for a gentle, leaky filter is a logical compromise, even if it leaves the audible band vulnerable to folded-back aliasing.
Regarding sample rate conversion (SRC) in general, performing arbitrary SRC when it isn’t strictly necessary is usually unadvisable. The quality of real-time resampling varies wildly, and while offline non-real-time methods have become remarkably transparent, they remain imperfect. However, if Engine’s audible artifacts are primarily caused by ultrasonic reflection due to a leaky low-pass stage, offline pre-SRCing your files using high-tap linear-phase filters might ironically yield cleaner playback by stripping out high-frequency energy before Engine’s real-time DSP ever processes it.
@Reticuli I have checked playback of the clean test file that was uploaded here. You can check this too.
The file contains a 440 Hz reference tone, that’s an A. Playback delivered clearly that note/tone, an A. The problem stated was that certain of these m4a files play slower on first import and analysis, as if the 48 kHz content was interpreted as 44.1 kHz content. That is very specific. It is not that they wrote that their cymbals sound strange …
If the 44.1 kHz interpretation situation is true, we can calculate the resulting playback tone:
440 Hz x 44.1 / 48 = 404.25 Hz … and that is no longer an A, it’s somewhere between G♯4 and G4, since G♯4 is 415.30 Hz and G4 is 392.00 Hz … in any case, that is a difference I would definitely hear …
So, the test file plays fine in Engine DJ and on the SC6000M. I don’t have a Prime 2. And we haven’t heard any news about the problematic files. Why and how are they different? I would like to know what the analysis showed there …
MP4/M4A has several places where timing and sample-rate-related information can occur, and AAC itself has its own AudioSpecificConfig, I don’t claim to know them all, this file format is alien to me 
… but I enjoy a good whodunnit.
So far, @st.cool has not posted new info about the problematic files. And these are the files we would need to reproduce odd behaviour …
I played around with the clean and unproblematic test file, I left the content unchanged, but changed the info in the container.
test-files.zip (673.9 KB)
| File | Expected if our metadata hypothesis fools Engine | Result |
|---|---|---|
| 01_clean.m4a | A = 440 Hz | 440 Hz ok |
| 02_declared_44.1.m4a | ~404.25 Hz ≠ A | 440 Hz  ?! |
| 03_declared_48.m4a | A = 440 Hz | 440 Hz ok |
| 04_control.m4a | A = 440 Hz | 440 Hz ok |
Yeah, surprise! Expected is not what happened. All these versions played back perfectly fine in Engine DJ and on the SC 6000M, clearly an A, 440 Hz, all of them analysed as 11B, which corresponds to A major …
There was one weird exception: the small waveform of 03_declared_48.m4a was not rendered completely, and the option to re-analyse it was not present in the context menu. Since this file is byte-for-byte identical to the original, I don’t know what to make of that yet. It may simply be an Engine DJ analysis/cache oddity (?) … weird. Edit: file was still loaded to a deck, hence no re-analyse option (thank you @MrWilks).
We can look at interesting places in these files:
File size: 194,843 bytes
Target: 0x2F08D (192653)
0002F06D 00 00 00 5A 6D 70 34 61 00 00 00 00 00 00 00 01 ...Zmp4a........
0002F07D 00 00 00 00 00 00 00 00 00 01 00 10 00 00 00 00 ................
0002F08D BB 80 00 00 00 00 00 36 65 73 64 73 00 00 00 00 .......6esds....
0002F09D 03 80 80 80 25 00 01 00 04 80 80 80 17 40 15 00 ....%........@..
At 0x2F08D we have:
BB 80 00 00
which represents 48000 Hz in 16.16 fixed-point in the mp4a AudioSampleEntry.
I changed it in the second file, 02_declared_44.1.m4a, to:
AC 44 00 00
which represents 44100 Hz in 16.16 fixed-point. 
File size: 194,843 bytes
Target: 0x2F08D (192653)
0002F06D 00 00 00 5A 6D 70 34 61 00 00 00 00 00 00 00 01 ...Zmp4a........
0002F07D 00 00 00 00 00 00 00 00 00 01 00 10 00 00 00 00 ................
0002F08D AC 44 00 00 00 00 00 36 65 73 64 73 00 00 00 00 .D.....6esds....
0002F09D 03 80 80 80 25 00 01 00 04 80 80 80 17 40 15 00 ....%........@..
MediaInfo shows a sample rate of 48 kHz in both cases. And Engine DJ plays it correctly. But the mp4a sample rate entry has been changed. This suggests that Engine is obtaining the effective 48-kHz information from somewhere other than this mp4a field …
I have not touched the esds (Elementary Stream Descriptor) atom or AAC configuration … but that is another candidate place where the actual sample-rate info comes from (?) … and there is the stts (Time-to-Sample) atom, it looks interesting too …
Established:
Engine DJ and OS can play 48 kHz m4a files. Engine DJ and OS can play 48 kHz m4a files with a conflicting 44.1 kHz value
in the mp4a audio sample entry box samplerate field - which is maybe not striking, but a result. This particular metadata mismatch does not reproduce the reported bug. At least not here with Win 11, latest Engine DJ and OS and the SC6000M as a player …That leaves the question:
Which piece of information does Engine DJ use to establish the relationship between AAC frames and playback time?
However, this is speculative … @st.cool could run some spectacular diagnostics on the files that cause the issues …
I think if the track is loaded to the deck in Engine DJ you can’t re-analyse it. Double check it wasn’t loaded and if it is eject it and try again.
I could be wrong but I think it’s from the depths of my mind.
Thank you! Yes, the track was still loaded, that was the cause - my bad! 