BPM Detection Algorithm accuracy EP v1.5, very disappointed

[jatoro]

Hi,

I want to share my frustrating experience with the promised announcement of the accuracy in the analysis of the BPM and, therefore, Beatgrid of the tracks in the new Engine Prime v1.5. I am convinced that, on this way, Denon has taken a step back, rather than forward.

After a while I had not decided to update to version v1.5, in the meantime I did not read that it complied with the comments of the forum confirming what was announced in corrections and improvements.

I have to say that the only thing I have noticed quite quickly is the management of the database, in terms of import and analysis, but if we gain in speed to the detriment of the accuract in the calculation of the BPM, this for me meaning that nothing is going well.

The last tracks I’ve been analyzing, old school style, years 1998-2005 Techno, Progressive, Trance, etc., most of the calculations come out rounded. For example where the previous version of Engine Prime v1.3.4 calculated 127.97980415, now it directly calculates 128, so the beatgrid bars are out of phase.

Is it so difficult and of little common sense, before fill with pride screaming to the four winds that you have improved the calculation process and detection algorithm of BPM, to contrast the calculation that different applications from the competition with experience and baggage in this world give?

For the same track above: Traktor: 127,980, VDJ: 127.98 …

Now I understand why you have not released yet a firmware update for Prime series devices.

Directly, Denon Team, abort the operation, if this firmware is going to be based on the same algorithm as Engine Prime, it will be a disaster.

Dedicate yourselves and ¿your time? (by the way, I hope you are enjoying your long vacational period) to enabling beatgrid editing functions in firmware, elastic beatgrid, tap, etc. that DJs and human beings in general, at this rate, we will be doomed to constantly correct the calculation of bpm in the air with your primitive software.

Regards.

[S_Anderson]

Several forum members, myself included have noticed and commented already that Engine Prime 1.5 is calculating BPMs more accurately than it was before.

I’m not sure what types of music you or the other delighted forum members play, but I’m open-format, so I’ll play almost any type of music and need it BpMd accurately. There’s certainly been an improvement in the bpm detection in the wide ranges and genres of music that I run through Engine Prime.

This period of waiting that we’re in right now, in between Engine Prime getting its significant upgrade to bpm detection, and the individual primes hardwAres bpm detection making it into firmware releases is bound to be more to do with the logistics of launching several firmware upgrade bundles, rather than denon second guessing themselves or the new Engine Prime 1.5 Algorithms. If there was a problem, they would have just waited a bit longer and adjusted Engine Prime first.

[PKtheDJ]

I can’t believe someone’s complaining over .02 (point zero two) of a BPM.

[yeltsin]

I think he’ll find mathematically with rounding 127.9798 is the same as 128.980 anyway, just more precise!

[JonnyXDA]

My guess is that your files have BPM/tempo ID3 tags at 128. Both Serato and Traktor write this information to the ID3 tags.

Currently EP uses this value rather than its own algorithm if it’s present.

[mufasa]

Try using reanalyse with that track.

Or post the track here and I can test for you at my end.

[Engell]

The new bpm algorithm is WAY better than before.

Try to remove all the original bpm data in the ID3 tag from a couple of tracks, and re-scan those.

I dont think Denon has gone on vacation. I believe they work pretty hard on getting the latest 1.5 implemented in to the players firmware.

[jatoro]

Thank you all for your point of view and share your particular experience with this new version.

Just one question for everyone: Why, as I said, EP version v1.3.4 detects the correct BPM: 127.98 and EP v1.5.0 no detects correctly (128.00), both with the same track, same metadata and importing from Traktor 127.98?

@PKtheDJ with all due respect, you have no idea what 2 hundredths in decimal calculation can affect the grid setting, and thus loops, beatjumps, sync etc.

@JonnyXDA No, that is not the reason, since, as I say, in both versions of EP I import the same file with the same metadata information.

@mufasa thanks, I have sent the download track link privately.

@Engell I cannot say from my experience the same, I have many miscalculations in mp3 tracks, which before, although they were not as exact as Traktor or VDJ, were more approximate than now.

[JonnyXDA]

@JonnyXDA No, that is not the reason, since, as I say, in both versions of EP I import the same file with the same metadata information.

You didn’t check the files. I specifically mentioned the files and yes that can be the reason. 1.3.4 is completely different from 1.5.0 - I’ve read a lot of posts like yours and in my experience, 95% of them are because of the ID3 tag.

If you remove the ID3 tag from the files and it still gives an incorrect BPM then we have more information to go on, however, as this is the most common problem it should be the first thing to try and eliminate.

I know as a fact that Serato writes the tag to the nearest whole number, I suspect the same with Traktor if the files have that in the tag, you should remove it, reimport track metadata then reanalyse it and let us know the results.

[PKtheDJ]

@jatoro

you have no idea

Haven’t I? How long have you known me? I would be willing to bet I’ve been DJing longer than you.

Do you honestly believe the “correct” BPM is 127.98? Why, because that’s what Traktor says?

I find it very hard to believe any artist/producer would release a track that’s 127.98 rather than 128. And yes, I’ve produced and remixed commercially released music too.

[mufasa]

Ok. I tested the MP3 track after stripping away all the BPM information. I even made a m4a duplicate.

In EP 1.5 the BPM is 128 flat. The beat grids drifts because it is not a 128 bpm track

I checked in Serato it is 127.98, Serato displays it as 128 but if you double click on the bpm it will show you its 127.98

@PKtheDJ

Do you honestly believe the “correct” BPM is 127.98? Why, because that’s what Traktor says?

It is 127.98 in Serato as well.

@jatoro

Why, as I said, EP version v1.3.4 detects the correct BPM: 127.98

I tested in Engine Prime 1.3.4 and it is also 128bpm flat with resulting inaccurate beat-grid just like in 1.5.

No algorithm is perfect, but still worth filing a report to ask for improvement, the algorithm is always been worked on

[JonnyXDA]

Okey dokey then, at least that gives the Denon DJ devs more information to work with and eliminates one possibility.

Since this track is analysed the same with 1.3.4 as it is with 1.5.0 with the native algorithm, this is not a new issue in 1.5.0 rather that is is an issue with the track import solution you used in 1.3.4 vs the current one in 1.5.0 - there is a known issue in 1.5.0 with Traktor import specifically so maybe that is the root cause of this - I think a bug report has already been posted. The OP should add his account to the report as well.

[jatoro]

Hi @mufasa, thanks a lot for your time and dedication to studying my case and contrasting if what I have exposed you could reproduce as it is and, therefore, it was correct, that there is no improvement in the analysis and detection algorithm of BPM.

I have to point out and emphasize that I ALWAYS IMPORT FROM TRAKTOR, since it is the application I have always worked with, before acquiring 2 Denon SC5000M units, and I note that I will have to continue working with Traktor in parallel for greater detection efficiency of the BPM and, consequently, beatgrid. (I don’t analyze tracks directly from EP, which is why both versions of EP v1.3.4 and v1.5 give you a value of 128BPM).

It is curious that, even importing the collection in both versions, v1.3.4 gives a BPM of 127.978:

This does not happen, however, doing the same process in version v1.5, it always returns a 128BPM analysis. And this calculation error of 2 hundredths translates, as I tried to explain to @PKtheDJ, although he does not want to understand it, as you will have been able to verify in the lag of the bars of the grid, even if it is from 2 and a half minutes onwards.

In short, and having said the above, currently I have no choice, if I want to prepare a music set on an external SD, Pendrive or external hard disk to introduce into the Denon SC5000M, that:

1. Create the folder and playlist structure in Traktor with the tracks I want.
2. Analyze them with Traktor, which of course gives me a lot more trust in the calculation and detection of BPM.
3. Import it in EP version v1.3.4, which at least seems to be closer to Traktor’s calculation (not EP v1.5).

And so, with the combination of both, at least, I can take advantage of these amazing units in hardware, but very primitive and with much to improve (although currently I see neither the development team will to meet the requests of users, nor professional work nor reflected in Future betas available to the forum so that users can contribute.

A greeting.

[mufasa]

@jatoro

It is curious that, even importing the collection in both versions, v1.3.4 gives a BPM of 127.978:

Best to add that information to the bug report

Before 1.5 I was using Serato for BPM analysis as that was what I was comfortable with having used it extensively for the past 12 years or so.

Hopefully they introduce a way to actually stretch or squeeze the beatgrids on the players as well in the future.

Because a tiny stretch at the end of that track will correct the BPM

The downbeat was identified correctly by EP

[Reese]

@jatoro

that there is no improvement in the analysis and detection algorithm of BPM.

That’s not true. The amount of tracks that were wrong in my collection was far greater with EP before 1.5. All wrong tracks I’ve submitted to devs are now spot-on. Almost everybody using the old EP complaint about the old analysis, but there’s always an exception to the rule.

On another note. The old house tracks were mostly of, because of old midi sync and the strain on the computer used. So the set 128bpm dropped a little bit; sometimes even during the track if more instruments became active in the midi network.

[jatoro]

@Reese The style of music I usually play ranges from house, through tech house, progressive, trance to techno.

It is true that I have been playing music for almost 3 decades, and according to which parties I am invited, the style and the track epoch varies.

I also agree with the current tracks, especially if they are original and directly purchased from official music portals, the BPM with which they leave the studio are exact, with decimals to zero, which makes it easier for the software to detect the hits below.

However, I wonder: If Traktor, Serato, and VDJ’s BPM detection algorithm can handle a huge percentage of different tracks, styles, decades, with high precision, why the Denon Engine can’t?

You said: “…but there’s always an exception to the rule” That is for me “the exception that confirms the other rule”. The small glitch with which a train leaves the factory, that has not been monitored or fixed, and could drift a lot of passengers

I do not doubt that the music you are currently working with is analyzed almost perfectly by the current version of EP, although I imagine it must be only recent, from the last decade, with not very complex styles and patterns and, perhaps without great creativity and variations in the productions (because none of you talk about the style and year of the tracks or some details of name and artist) that you say has brutally improved the analysis)

For me a software today that is not capable of calculating the correct BPM, for the wide range of music, styles, decades, even slightly non-homogeneous or uniform tracks, with a very small margin of error, it is not only highly deficient, but it leads to being invalid to play live, because any DJ may have the need to burst the dance floor at some point with one of these tracks and disaster can occur.

Like @mufasa said, if Denon development team is unable to improve BPM detection algorithm in previos mode i explain, “Hopefully they introduce a way to actually stretch or squeeze the beatgrids on the players in next firmware versions”.

[Jetsound]

You’re making such an overkill go at this I’m wondering what the subtext is. It’s far more than just the surface glimmer.

If denon can tweak the bpm algorithm at some point in the future, then that’s “nice” but far from the most important thing

[PKtheDJ]

@Reese

old house tracks

In the early days yes - but not in 2005, years after synths were hosted in DAWs. Listening to this thing, it’s not exactly a busy track anyway. It’s not going to stress a computer, even if it is an old Atari ST running Pro 24 with 5 pin DIN cables snaking out of it

We’re still talking about point zero two of a BPM. At 128 the grid isn’t miles out, even right at the end of this eight minute long drone.

[sigh] I remember the days… mixing vinyl, with no beat grids, no waveforms, no BPM readouts. We still managed to keep things in sync. Aren’t ears wonderful?

[yeltsin]

You felt like a god if you kept a mix together for 3+ minutes, now sometimes if I’m practicing I don’t even use headphones, just the BPMs on screen and still be 99% accurate.

[mufasa]

@PKtheDJ

I remember the days… mixing vinyl, with no beat grids, no waveforms, no BPM readouts. We still managed to keep things in sync. Aren’t ears wonderful?

But djs couldn’t beat-jump back in this golden era, or loop? or roll a track?

Just back to back track mixing or in the style of David Mancuso, just dropping it on the 1.