wrote:- KingGuppy added more ROMs (though, few still unavailable)
- DOSBox patch works with legacy only but I'm working on the quick update
Regarding ROMs. There is a bug in the 1.00 version (March 89) of the CM-32L that can cause clicking and popping under certain conditions. Version 1.02 (Dec 89) doesn't have this issue.
But you're likely aware of this already...
Regarding the decaping:
You gave the analysis of the ROMs (which I understand are just lookup tables?).
Does this process also help analyze the functional logic of the chip?
I wanted first of all to thank all the people who are involved in the revival of the Munt project, the quality of emulation is much better than on previous attempts, makes me wish I could contribute somehow to it.
My question would be, there seems to be some sort of frequency cutoff in the emulator, as I've made some comparisons with recordings from real hardware and what I've noticed is that some instruments sound a bit "muffled". I know in the original Munt, the sound was very muffled and unclear, so I think the reloaded Munt has done some considerable improvements. ^^
I've attached some examples, my recordings of the emulated MT-32 are in .ogg format while the ones made with real hardware (from RMLA.co.nr, they record using sound trackers and Sierra SysEx drivers and playback midis, which isn't that great but still good for comparison). The most noticeable muffle is heard in percussion instruments but also in some synth-like instruments. So my question would be... is this muffled sound a emulation "mishap", or can it be turned off somehow? I am working on a project (see all my IBM-PC recordings here: http://vengefulchip.tk/ibm-pc-adlib/ =) ) on which I record chiptunes, and would like my recordings to have a crisp sound, hence the question.
Oh, and wish everyone here a happy new year ^^
Yeah, I completely agree, it's a Roland's miss that MT-32 & compatibles have no built-it equalizer... 😁
I wonder if you could code in a default location for the Roms when using the mt32lib? Afai understand it is using the folder from where you start whatever program is using the lib.
My proposal would be ~/.mt32 on linux, /library/application support/mt32 (or in the userspace ~/library/application support/mt32) on Windows perhaps $LocalAppData/mt32.
wrote:Yeah, I completely agree, it's a Roland's miss that MT-32 & compatibles have no built-it equalizer... 😁
Well, I was rather asking for a solution to the frequency cutoff, not to add equalizer effects =P
On a closer inspection with a spectrogram on a MUNT recording, I noticed that it's not your standard cutoff, but rather a frequency range being diminished between roughly 15500 and 17000Hz. Here's a screenshot of of the spectrogram so you could see what I mean:
@Dominus:
You're right, KingGuppy has already proposed such a suggestion but probably didn't commit it (or had no time to implement).
@marooned_on_mars:
Your're also right 😀
Though, comparing analogue samples resampled to 44100 or 48000 Hz adds some sort of uncertainties. But I have looked at FFT spectrum quite some time ago and it displayed a big difference. As I have already said somewhere above, we use floats but LA chip uses integer 16-bit (or possibly 18-bit) logarithms. So it creates some noise. But it is no match to the differences between the files you've posted.
I can post two recordings of Dune-2 (for instance) made at 32000 Hz without any postprocessing in trackers, etc. It's _barely_ distinguishable.
Also note, we recently improved the reverb much. But from what I can hear, reverb is _way_ different in your recordings.
Thanks, looking forward to this 😉
wrote:@marooned_on_mars: Your're also right :) Though, comparing analogue samples resampled to 44100 or 48000 Hz adds some sort of unc […]
@marooned_on_mars:
Your're also right 😀
Though, comparing analogue samples resampled to 44100 or 48000 Hz adds some sort of uncertainties. But I have looked at FFT spectrum quite some time ago and it displayed a big difference. As I have already said somewhere above, we use floats but LA chip uses integer 16-bit (or possibly 18-bit) logarithms. So it creates some noise. But it is no match to the differences between the files you've posted.
I can post two recordings of Dune-2 (for instance) made at 32000 Hz without any postprocessing in trackers, etc. It's _barely_ distinguishable.
Also note, we recently improved the reverb much. But from what I can hear, reverb is _way_ different in your recordings.
So if I understood correctly it's a emulation mishap? Nothing can be done about it then, I suppose.
I'll try to change MUNT's settings to 32000Hz but since I do all the recordings at 48000Hz, it might be a bit problematic. As for the difference in reverb, I used the latest patched DosBox binary from your GitHub (before they disabled downloads), so I'm unaware what MUNT build number it is.
Pardon my ignorance but I don't really know how to compile/build a custom DosBox, and I would've preferred to use the win32 driver, but that would make it harder to record sound (I have an slower PC and the recordings would have lots of skips).
wrote:So if I understood correctly it's a emulation mishap? Nothing can be done about it then, I suppose.
<skip>
Nope, it's a comparing-not-knowing-what-you-are-comparing problem.
FYI: smf2wav is created just to do perfect digital recordings
The best way to do compare, and what we actually do, is comparing digital recordings. KingGuppy has a digital capture tool, and IIRC proposed making such a recording to anyone who wants 😀
wrote:Nope, it's a comparing-not-knowing-what-you-are-comparing problem.
FYI: smf2wav is created just to do perfect digital recordings
I didn't use the smf2wav tool while recording the OGG examples above, I used the pre-compiled DosBox binary that was on Munt's GitHub and that was last time updated on 22nd of December last year (or maybe you meant something else by mentioning smf2wav? ). Can someone please direct me how to compile .patch files into DosBox and where are the latest MUNT patches?
Recording using DOSBox is discouraged. DOSBox patch feeds wave at 32000 Hz and it is then resampled by DOSBox's mixer corresponding to your settings. BTW, note that 16000 Hz is the Nyquist frequency for LA synth.
smf2wav build for win32 is @ sf.net ready to use (almost, you still need those ROMs)
If I didn't convince you, the DOSBox patch has been moved to the main repo:
https://github.com/munt/munt/tree/master/DOSBox-mt32-patch
And one more note: mt32emu-qt has an AudioFileWriter output that will simply record the wave currently being played (though, no echo) to a file. You can also capture & write a .mid using the "Record" button (the way I personally prefer).
wrote:Recording using DOSBox is discouraged. DOSBox patch feeds wave at 32000 Hz and it is then resampled by DOSBox's mixer correspond […]
Recording using DOSBox is discouraged. DOSBox patch feeds wave at 32000 Hz and it is then resampled by DOSBox's mixer corresponding to your settings. BTW, note that 16000 Hz is the Nyquist frequency for LA synth.
smf2wav build for win32 is @ sf.net ready to use (almost, you still need those ROMs)
If I didn't convince you, the DOSBox patch has been moved to the main repo:
https://github.com/munt/munt/tree/master/DOSBox-mt32-patch_______________
And one more note: mt32emu-qt has an AudioFileWriter output that will simply record the wave currently being played (though, no echo) to a file. You can also capture & write a .mid using the "Record" button
smf2wav doesn't really adhere to my needs, since what I'm aiming is to record music faithful to what the game produces. Same goes to recording after midi files X.X
I tend to use DOSBox since it's the only way to get into the game and "cause" games to output their music.
All that I'm interested in is to have a crisper sound, and I'm still not yet sure how that would be possible. If I changed MUNT's settings to 32000Hz, would it change anything? Also, wouldn't mt32emu-qt record the audio skipping too? By echo do you mean reverb?
Ah, that Nyquist frequency explains the "cutoff" in the recording around that range.
Yep, real units have incorporated anti-aliasing things, so they produce no sound @ about 16 kHz. But after you have recorded a track, you can easily post-process it and add more color to the sound. And I suspect most of those recordings around the net are just post-processed and do confuse many people. Police Quest 2 intro theme @ Quest Studios sounds even like several patches playing are different 🤣.
wrote:Yep, real units have incorporated anti-aliasing things, so they produce no sound @ about 16 kHz. But after you have recorded a track, you can easily post-process it and add more color to the sound. And I suspect most of those recordings around the net are just post-processed and do confuse many people. Police Quest 2 intro theme @ Quest Studios sounds even like several patches playing are different 🤣.
Not sure how accurate the recordings are from RMLA.co.nr, since they use noisetracker and Sierra's SysEx driver to playback midi files (not quite sure what container they store the game music), but they use real hardware, and apparently none of their recordings have any muffled recordings. So I ask again, are the muffled instruments (especially percussion) normal?
For your consideration, here you are Zeliard title recording. Sampled at 32000 Hz.
You can clearly hear the difference in the attack phase of one patch. This is due to a bit inaccurate TVA/TVF ramping time. But there is no any problem with PCM patches. And most of drums/hats patches are plain PCM samples.
And yes, FFT spectrum displays how noisy LA32 is.
wrote:For your consideration, here you are Zeliard title recording. Sampled at 32000 Hz. […]
For your consideration, here you are Zeliard title recording. Sampled at 32000 Hz.
______________
You can clearly hear the difference in the attack phase of one patch. This is due to a bit inaccurate TVA/TVF ramping time. But there is no any problem with PCM patches. And most of drums/hats patches are plain PCM samples.
And yes, FFT spectrum displays how noisy LA32 is.
Thank you for taking your time and recording those. I notice that your MUNT recording still has muffled percussion instruments compared to the CM-64 version, so then that means this is the best I can get with emulation, but I'm happy with this too, since the emulation is still relevant. Thank you again for sitting through my questions and helping AND for the awesome development to MUNT ^^
