Sound Editing Section

[kenjwright]

Jan 28, 2024 16:03:40 GMT -5 Falko76 said:

BTW I run "ddrum4edit -c config.cfg" to create .mid file, maybe here some parameter is missing?

That is the correct (and only) command parameter required when creating from scratch.

I just duplicated the test on a 2016 server (64bit) with the same successful results so still stumped as to what is going wrong ;-{

 

[falko76]

Tried my PC, laptop, my son's PC, my daugher's PC - all yielding same wrong results (just 7795 samples without the 44100 part). Maybe it's the environment to test - all 4 PCs are different hardware, but same environment - Windows 10 Pro x64. So maybe I try virtual machine, but what Windows version to try?

[kenjwright]

Man, this just keeps getting weirder!! 

I just ran the test on an HP laptop, Windows10 Pro, 64bit with success. Each release is complied on a Windows10 32bit VM and tested on win98, win2000, windows10 VMs and sometimes on 2016 server (bare metal) if any issues appear (to rule out VM possibilities). So the errors you are seeing are puzzling. To confirm, are you testing on the exact same zip file contents that you provided?

Maybe we can start with a fresh config? 

• ddrum4edit -e to created a new default.cfg.
  
• Edit default.cfg to include only one of the .wav files.
• Edit default.cfg to include only one Cue setting of S1 0.099 8000
• ddrum4edit -c default.cfg
  

Then let's see results.

Cheers!

Ken

[falko76]

Yes I was testing the same zip folder. Now I did what you said above.
Here's the result:
drive.google.com/file/d/1IeYGhMq_6XdUIkiq6_BBLVE-PMKN7tRE/view?usp=drive_link
Starts again at 7795 samples so not sure if its correct already as the only cue is S1 0.099 8000 (so not from start of sample)
Anyway I also tried two cues: S1 0.00 41000, S1 0.099 8000 , but the output is the same (starting at 7795)
Also, when I did ddrum4edit -e, a new file showed up, which I didnt use before - default.smp, is this required for making .mid file out ouf samples and .cfg file? But this time that file was present and resulting .mid is with this file present.

I will have to try some external PC, a friend's of mine or something, to see if it works 
BTW there is also config.cfg in this zip which I forgot to delete, but its irrelevant as its not used, as I made .mid with ddrum4edit -c default.cfg

[kenjwright]

default.smp is only there as an example and not required for anything. It is a very small KICK sample (I forget which one).

I was not able to access the file on google but submitted an access request. I'm guessing you will see that soon.

[falko76]

Jan 29, 2024 15:36:35 GMT -5 kenjwright said:

default.smp is only there as an example and not required for anything. It is a very small KICK sample (I forget which one).

I was not able to access the file on google but submitted an access request. I'm guessing you will see that soon.

sorry, access fixed

[kenjwright]

Still cannot make it fail. 

Try updating default.cfg with the following two cue markers;

S1 0.019 22050
S1 0.199 8000

[falko76]

There should be access, maybe clear cache? Anyway, I made a new zip here with two cue markes as above

S1 0.019 22050
S1 0.199 8000

Link
drive.google.com/file/d/1HNbEDzVWqM1cDGl7V3RP_AsZP1Ziznid/view?usp=sharing

This time I run it with different versions of ddrum4edit. There are resulting .mid files included. What's interesting filesize differs from version to version
v1.00.03 - makes .mid but ddrum4TOOL hangs upon clicking "listen"
v1.00.04 - makes same .mid as above
v1.00.05 through to v1.00.15 - makes tiny 1219 bytes mid and ddrum4Tool doesnt hang, but no sound
v1.00.16 to v1.00.22 - makes big 354kb mid
v1.00.23 to v1.00.28 - fails to make mid, while doing it, it prints dots constantly to the screen, so have to break it
v1.00.29 - this version produces sound from ddrum4Tool, but it's all at 7795hz
v1.01.00 - same output as v1.00.29

versions from start up to v1.00.28 are unusable for ddrum4TOOL, either hang or produce no sound when "listen" pressed, so I guess I was pretty lucky, the first ddrum4edit I used was v1.00.29 which does produce sound, so I didnt get discouraged from the very start that something is not working and I had immediate results (but cue problems afterwards) :-)

I have also tried with no cues at all, results:

v1.00.03 to v1.00.22 - makes same mids as their version counterparts with cues
v1.00.23 to v1.00.28 - as with cues , fail to make mid, dots print out
v1.00.29 and v1.01.00 - correct 44100 mid file

So from my PCs only versions v1.00.29 and v1.01.00 produce any usable .mid

[kenjwright]

Wav file support was added in 1.00.23, cue markers in 1.00.27, and >16bit multi-channel support was added in 1.00.29. So it is expected that various degrees of failure would occur in earlier versions.

Still not able to replicate your issue. But one thing we could try, just to reduce variables, would be to have your wav file rewritten to 16 bit mono. Just shooting in the dark now because nothing logical has surfaced yet. But that should also allow 1.00.23 and greater to be successful.

Ken

[falko76]

Conversion looks ok as tried 16 bit mono wav sample and produces same mid file

In the "reading riff file" section it (I think) correctly recognizes cues, as it says waveSize= 88192 samplerate=44100, then waveSize=15588 reSamplerate=7795 when I try S1 0.0 44100, S2 0.2 8000

[kenjwright]

Ok, if you could please add the -d (debug) parameter to the command in 1. Run to create mid file.bat

ddrum4edit -c default.cfg -d

It will generate a lot of noisy output but hopefully you can capture without losing too much due to windows scrolling behavior.

[falko76]

drive.google.com/file/d/16bjhr5h_0PQKaia2uifxyYMtwiissH1Q/view?usp=sharing
this time to save space and unneccessary converting, sample is 16 bit mono. Cues are S1 0.0 44100, S1 0.2 8000
debug is as jpeg, captured with print screens and merged in photoshop :-)

[kenjwright]

Now we need more cues markers. Using -d again please.

Please skip 44100 altogether and add only these;

S1 0.019 32000
S1 0.040 22050
S1 0.199 8000

[kenjwright]

I think I may have stumbled on to the issue. Your systems are in Europe and using the comma as the decimal point and the dot as the thousands separator. Que Markers are the only place in the cfg file where decimal values are used. If I am correct, then you can change the cue markers to this;

S1 0,019 32000
S1 0,040 22050
S1 0,199 8000

Fingers crossed...

[kenjwright]

Actually, that is the exact issue. Proved it locally and implemented the fix.