Getting the raw audio samples data

[kamen]

the link has been updated
https://www.mediafire.com/file/sl0k311vrbbs66j/MusicBeeBass.dll/file

Very good results!

The data is now correct and the function triggering on startup is now fixed.
Compared to the DSP, the Raw API is visibly a lot more responsive and immediate - truly real-time!

I have a couple more issues, that I noticed:
1) disabling the C++ plugin crashes/closes MB
2) changing the audio output (in preferences) stops the triggering of GetPCMRawData.
3) About the quality of the data:
- It looks to be sampled at 44.1khz and upsampled to the audio file sample rate, for audio files up to 88.2khz. For audio files above 88.2khz, it remains the at 88.2khz, which is still upsampled 44.1khz.
- For my tests with the frequency band algorithm from TF3RDL, I get proper spectrum information only up to 22.05khz, which is equal to the DSP api and corresponds to 44.1 sampling rate.
- The MB GetSpectrumData function on the other hand delivers spectrum that corresponds to the actual file sampling rate. Is there a way to get comparable behavior from GetPCMRawData?

Thank your for your efforts.

[Steven]

for the first 2 issues, the link has been updated
https://www.mediafire.com/file/sl0k311vrbbs66j/MusicBeeBass.dll/file
and also
https://getmusicbee.com/patches/MusicBee36_Patched.zip

I dont get your statements about resampling. MB is just intercepting the DSP chain from bass after it has decoded the raw data and before the data is sent to the output device. Unless you have the "resample to" option ticked in the player preferences, I dont see why bass would resample anything ie. the data you receive should be the sample rate from the source file. However there was a bug in MusicBeeBass.dll now fixed which i guess might somehow have affected what you  were seeing.

[sveakul]

If he's mistakenly using Wasapi-shared he would end up with output resampled by Windows to whatever the Windows Mixer was set to, no matter what he set/didn't set in MusicBee, correct?  Wasapi-exclusive needs to be used.

Also:  the updated MusicBeeBass.dll was not contained in the MusicBee36_Patched.zip in the same post--does this mean others should hold off on replacing the DLL yet?

[kamen]

for the first 2 issues, the link has been updated
https://www.mediafire.com/file/sl0k311vrbbs66j/MusicBeeBass.dll/file
and also
https://getmusicbee.com/patches/MusicBee36_Patched.zip

I dont get your statements about resampling. MB is just intercepting the DSP chain from bass after it has decoded the raw data and before the data is sent to the output device. Unless you have the "resample to" option ticked in the player preferences, I dont see why bass would resample anything ie. the data you receive should be the sample rate from the source file. However there was a bug in MusicBeeBass.dll now fixed which i guess might somehow have affected what you  were seeing.

Your statement that bass doesn't do any additional resampling is enough for me at the moment. I'll try to run standard FFT to verify that, but it will take some time. Up to now I only compared the sizes of the data streams per second and used a frequency band transformation to check the spectrum structure visually. The latter might not be the ultimate proof for resampling or cut off frequencies, that I am suspecting, but here is how it looks like for a 48khz audio file:



Also my report on the three issues in your latest version:
1)Disabling/enabling the c++ plugin is fixed.
2)Changing the device output also works, but there is some regress. If I use the player next/previous track controls or select a song other than the played on startup, the RawData function never gets called again... unless I change the output settings!
3) Now the DSP stream is no longer fixed at 44.1khz, but equals the raw data stream size. Won't this break the functioning of some older winamp plugins?

[kamen]

If he's mistakenly using Wasapi-shared he would end up with output resampled by Windows to whatever the Windows Mixer was set to, no matter what he set/didn't set in MusicBee, correct?  Wasapi-exclusive needs to be used.

Also:  the updated MusicBeeBass.dll was not contained in the MusicBee36_Patched.zip in the same post--does this mean others should hold off on replacing the DLL yet?

We are comparing the audio data before being passed to the output driver/device. I mixed up WSAPI and ASIO during the testing, because it changes the data chunk size on each RawData or DSP function call.

[Steven]

2)Changing the device output also works, but there is some regress. If I use the player next/previous track controls or select a song other than the played on startup, the RawData function never gets called again... unless I change the output settings!

this should work
https://www.mediafire.com/file/sl0k311vrbbs66j/MusicBeeBass.dll/file

[kamen]

2)Changing the device output also works, but there is some regress. If I use the player next/previous track controls or select a song other than the played on startup, the RawData function never gets called again... unless I change the output settings!

this should work
https://www.mediafire.com/file/sl0k311vrbbs66j/MusicBeeBass.dll/file

Yes, it works!
This allows me to test it for a while and fix my own plugin issues around it.

[TF3RDL]

This allows me to test it for a while and fix my own plugin issues around it.

Good, though it is not complete without replacing the built-in FFT method with a custom FFT routine that permit non-power of two sample lengths and even makes Mid/Side representations possible (if built-in method of getting spectrum data doesn't support Mid/Side mode)

Other forms of visualizations like actual oscilloscope and vectorscope should also be possible with new API

BTW, have you extensively compared your filter bank implementation within your plugin with my own implementation for a completely different platform? Like testing these two with test tones, white and pink noise to make sure they matched up with eachother and obviously, there shouldn't be any missing or overlapping samples, otherwise it would lead to "wrong" results (as expected on my own spectrum analyzer project when switching from AudioWorklet-based sample acquisition to AnalyserNode-based one)

[kamen]

I was able to test a bit more, including generation of a FFT spectrogram. The spectrogram results from the raw API and DSP are similar to the GetSpectrum function, which is a positive confirmation for the qualities of the streams.

During the testing I noticed two more small bugs:
4) A DSP plugin does not work anymore after disabling/enabling in "Equalizer/DSP Settings" using the checkbox. To work again I should disable/enable the menu entry "Control->DSP Effects" or restart MB. This seems to be a 3.6 bug, 3.5 was working correctly with that.
5) When an automatic change between two tracks in a playlist with different sample rates occurs, then the DSP and RAW streams remain at the sample rate of the first track. It works correctly again if I manually change the track.

Both tested with the most recent patched version.

[sveakul]

4) A DSP plugin does not work anymore after disabling/enabling in "Equalizer/DSP Settings" using the checkbox. To work again I should disable/enable the menu entry "Control->DSP Effects" or restart MB. This seems to be a 3.6 bug, 3.5 was working correctly with that

I noticed this too just a day ago testing settings for possible effects on VU meters--unchecking the VST in the settings box in real-time does disable its effect on the audio, but re-checking it does not re-enable it until MB is restarted.  Did not happen with 3.5, which would re-enable live as soon as the plugin was re-checked.

[Steven]

During the testing I noticed two more small bugs:
4) A DSP plugin does not work anymore after disabling/enabling in "Equalizer/DSP Settings" using the checkbox. To work again I should disable/enable the menu entry "Control->DSP Effects" or restart MB. This seems to be a 3.6 bug, 3.5 was working correctly with that.
5) When an automatic change between two tracks in a playlist with different sample rates occurs, then the DSP and RAW streams remain at the sample rate of the first track. It works correctly again if I manually change the track.

should work now:
https://getmusicbee.com/patches/MusicBee36_Patched.zip

[kamen]

Yes, both are fixed now.
Thank you!

[BoringName]

This data seems to be post REPLAYGAIN_TRACK_GAIN and RVAD tag values, is that intended?

I thought it was supposed to be raw data before any alterations.

edit: actually that makes sense, nevermind.

[Steven]

it is supposed to be before any volume adjustment. If you believe its not the case, I can spend some time testing it to confirm

[BoringName]

Disclaimer - I had a few drinks with dinner so the results could be questionable....

But from my testing it seems that both -
GetPCMRawData
and
NowPlaying_GetPeak

Both return values post track tags AND player EQ settings.

I haven't tested with any DSP plugins.

I've got an option setup to switch between the sources of data and they both display similar results when I adjust the Replay_track_gain tags or player equalizer settings.

Just to make it clear I'm not mixing things up and looking at the same source of data.

When I set the pre-amp in the EQ settings to +3db and run a test file at zero level I consistently get the following values -
GetPCMRawData - 1.412495
NowPlaying_GetPeak - 1.412538

If I disable EQ and set a +3db REPLAY_GAIN_TRACK tag I consistently get -
GetPCMRawData - 1.412494 (0.000001 difference)
NowPlaying_GetPeak - 1.412538

Setting both  +3db EQ pre-amp gain and +3db replay gain tag adds together as expected and returns a +6db(1.99) result from both data sources.

edit: This seems to be a consistent result with WASAPI Exclusive and WASAPI Shared.