Closed Hooperla closed 3 years ago
KaleidonKep99
commented
3 years ago I think this is caused by the audio engine's and events parser's threads getting out of sync. 18.3.2.0 will force both to run on the same thread, let me know if that fixes the issue.
KaleidonKep99
commented
3 years ago I managed to solve the issue with the random dropouts in the audio, but I wasn't able to fix the delay in the first few seconds of the encoded audio stream.
I think the only solution is to let BASS (OM's audio library) fill the data buffer a bit, then restart the playback from the beginning WITHOUT letting the MIDI player close the MIDI device (which clears the audio buffer). This can be done usually by dragging the seek bar to the beginning without pressing pause/stop. That seems to get rid of the issue. Of course, you then have to crop out the broken part using something like Audacity...
Hooperla
commented
3 years ago Thanks for replying and looking into this so quickly!
However, 13.8.2.0 seems to have a new issue, namely that I can't seem to do a conversion at all now. When I do the steps I described earlier, the Windows Media Player application simply opens for a moment and then auto quits itself. A file IS produced, but it is one without any audio or other data whatsoever (0.0 bytes).
I then tried uninstalling Omnimid and going back to 13.8.1.0 to make sure that something strange didn’t happen that was preventing me from using that function in general (made sure to use the same settings as before of course).
As expected, I was once again able to use the function, with the same errors as described before occurring as well. To make completely sure it isn’t some strange carryover issue, I then uninstalled 13.8.1.0 and reinstalled 13.8.2.0 as cleanly as possibly. This didn’t solve the issue unfortunately, the Window Media Player application still auto closing near instantly and leaving behind an empty file behind.
Just to be clear though, playing it in “Windows Audio Session API” still works just fine, just “Audio to .WAV mode” suddenly doesn’t work going from the older version to the new one.
KaleidonKep99
commented
3 years ago Could you please try version 14.x? I might have fixed the issue by updating the code for the new XAudio2 engine.
Hooperla
commented
3 years ago Did the tests and indeed it seems the conversions are just fine now! I only did three tests because I'm a bit busy at the moment, but all three conversions I performed sound correct to my understanding. In fact, the annoying problem of needing to stop the playback so the program can catch up and then starting from the beginning again seems gone too. Very good work! I put the conversions I did on MEGA for you too look at and listen to just in case I'm not noticing any errors, and I added a note that explains the settings that I used for the various conversions. At the current moment, I'll close this issue, but I'll make sure to inform you if I find anything else strange. Keep up the good work!
MEGA LINK (116.8 MB): https://mega.nz/file/pF1wGD4b#TFEk9MNkWuG01sffkxKA1af9zUHzNlUPPRuboiAWc9o
Problem When using the "Audio to .Wav" mode, the converted file, in most cases, has tiny errors that occurs (slight skips, sound stopping for a moment or two, etc). It also always produces a garbage area of sound at the very beginning of the midi file, requiring me to stop the midi files being played for a few moments and then replaying it so I have a clean recording.
Steps to reproduce
Expected behavior That once the conversion starts the midi will be recorded without errors throughout and without garbage area at the beginning. In other words, one can simply play the midi, wait for it to finish while doing something else, and expect it to sound correct as long as nothing is done to stop the recording (either by the user or by some force outside their control such as a power shortage or the like).
Screenshots/Videos I uploaded two conversions of the same midi (e2m1's doom midi called "I Sawed The Demons", as it has many notes to easily notice issues) that both had errors, which I documented in a little note for ease of finding.
I converted both with the same settings (mostly default, but a few slight things changed) and also put in screenshots of the settings that I used.
I also added Brandon Blume's (Aka. MusicallyInspired) authentic SC-55 version of the same song so that a clean comparison can be made between where the errors occur if needed.
Along with all that, I also added the soundfont (both the original version and modified version) just in case there is something with particular soundfonts that cause the issue.
The WAV files were converted to FLAC level 8 to reduce size.
For Conversion ONE, I let it play a bit to show how the recording starts with strange garbage area and then slowly becomes correct after a second or two. For Conversion TWO, I simply did what I usually do and quickly stop the playing of the Midi file, drag the place on the Windows Media Player time bar back to the start, waited a few moments, and then played it (this also has garbage at the beginning, but I went away from it quickly since Conversion ONE was made to showcase it more clearly).
Mega Link: REMOVED Archive Size: 90.3 MB (Sorry)
Environment
Additional context I have used Omnimidi for a long time but always had this error. Strangely though, after updating to the newest version, I found that I was able to get converted WAVs without issues. However, after about doing two of these, the errors seemed to reappear. I would have added those good conversions to the upload, but I was dumb and deleted them out of habit. Very sorry for that blunder, but I wanted to make it clear that I have been trying for a while, finally got a little success, and then it went back to its old ways again.
PS: Sorry if I didn't do this well, hope I gave you the information you need at least in some regard.