Closed TheEeveeLovers closed 9 months ago
I'll check this very soon. Sounds like a confusion with a chunk size or something. Even there is an unknown data section in the header, it should being properly skipped and ignored.
I tested your WAV file at the latest development MixerX version, and it works just fine. I had a bug because of pad byte (the length of data is always multiple 2, even the lenght value is odd). 073af71b2e47f45b659c7bb5fcb8fe0e610e1395
Please try to build the LATEST version of MixerX from the top of the branch master
, and try how it works.
@TheEeveeLovers, ping?
@TheEeveeLovers, ping?
Yeah sorry, I am trying to figure out how to set up compiler
What OS you do use? For Windows, there are several auto-builds https://builds.wohlsoft.ru/win32/ (you may find something that would work on your end). On Linux, it's pretty easy, just install gcc, g++, libsdl2-dev, cmake, and small stuff, and you can just build the thing via default CMake setup. You may also install Qt5 to build the GUI music player (need to enable build of examples first).
Sorry for the long wait, I just decided to prioritize other things. I am using Windows and Visual Studio Community 2022
This should just work. It builds on MSVC very easy. You can use Ninja-build or generate an VS-SLN project to build the thing using MSBuild. Actually, CI builds the thing for various MSVC versions and you could take any prebuilt things to verify the work on your end.
How would I go about generating a VS-SLN project? Google really hates me for some reason, can't give me a clear answer at all! I have written the prompt in at least 50 ways and ran out of stuff to throw off my desk! And don't even mention the Generative AI, its answers always contradicted my prompts!
Open the "Command line tools for Visual Studio" via shortcut in Start menu, then cd into clonned copy of MixerX, and then, you need to run something:
md build
cd build
cmake -G "Visual Studio 17 2022" ..
And after, open the .sln file that appears in "build" directory via IDE, or run the next command to build the thing in a place:
cmake --build . --target all --config Release
And after it got Built, there is built library should appear. You can copy it to your place and use in your project.
Apparently I'm missing a CMakeLists.txt file?
I decided to build with AudioCodecs instead. So... I was able to make a solution, but, there was one error sandwiched between 261 warnings It's a really long one, so be wary of that
Error MSB8066 Custom build for 'D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct36_x86_64.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct36_x86_64.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct64_x86_64_float.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct64_x86_64_float.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_float.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_float.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_s32.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_s32.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_float.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_float.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_s32.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_s32.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct36_avx.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct36_avx.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct64_avx_float.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\dct64_avx_float.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_float.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_float.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_s32.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_s32.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\getcpuflags_x86_64.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\getcpuflags_x86_64.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_accurate.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_x86_64_accurate.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_accurate.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_x86_64_accurate.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_accurate.S.asm.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\build\CMakeFiles\9caaa63e3f19540d36e4f6658009a6df\synth_stereo_avx_accurate.S.obj.rule;D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\AudioCodecs-master\libmpg123\ports\cmake\src\libmpg123\CMakeLists.txt' exited with code 9009. libmpg123 D:\TheNewWINDOWS\VS Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets 247
Most of the paths are in a 'synth' folder All of them point to a .rule file I guess libmpg123 doesn't want to follow the rules?
You can disable use of mpg123 via -DUSE_MP3_MPG123=OFF
during CMake run.
And also, disable build of MPG123 at AudioCodecs side:
-DBUILD_AUDIOCODECS_MPG123=OFF
via MixerX's CMake options.
Oh! One thing I forgot to note: to let mpg123 being built via MSVC, you need to download an executable of assembler, I forgot which is needed, I'll let you know when I'll remember...
Okay, I remembered! You need to separately download the YASM thing (https://github.com/yasm/yasm) and put it into any directory of PATH environment. That's a requirement for MPG123 to be properly built via MSVC toolchain. MinGW-w64 toolchain will build it normally as it has compatible assembler from out of box.
Ok I found the problem Apparently it was trying to assemble using YASM's containing directory as an executable instead of YASM itself In other words, it was trying to run a folder
OK after fixing that and continuing, there's a measly 190 errors when trying to build my program that uses Mixer_X
Looks like you built the release version of the thing when it's supposed to link a debug one :eyes: (Weird MSVC, it doesn't allow mixture of debug and release libraries).
Ok I changed the libraries to Debug ones and now the error count has shortened to only 22, all being unresolved externals if you count the one that says there were 21 unresolved externals.
Build started...
1>------ Build started: Project: SDL2_MusicPlayer, Configuration: Debug x64 ------
1> Creating library D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\x64\Debug\SDL2_MusicPlayer.lib and object D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\x64\Debug\SDL2_MusicPlayer.exp
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_create_context referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_free_context referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_load_module_from_memory referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_load_module_from_callbacks referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_release_module referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_start_player referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_play_buffer referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_get_frame_info referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_end_player referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_get_module_info referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_set_position referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_set_tempo_factor referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_stop_module referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_seek_time referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_xmp.obj) : error LNK2019: unresolved external symbol __imp_xmp_channel_mute referenced in function XMP_Load
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutOpen referenced in function init_midi_out
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutClose referenced in function close_midi_out
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutPrepareHeader referenced in function rtSysEx
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutShortMsg referenced in function update_volume
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutLongMsg referenced in function rtSysEx
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutReset referenced in function reset_midi_device
1>D:\TheNewWINDOWS\source\repos\SDL2MUSPLAY\SDL2_MusicPlayer\x64\Debug\SDL2_MusicPlayer.exe : fatal error LNK1120: 21 unresolved externals
1>Done building project "SDL2_MusicPlayer.vcxproj" -- FAILED.
I have linked all of the libraries that the AudioCodecs was able to build (I literally copied the output of dir /w *.lib
into the linker, making sure each library had its own line), which includes libXMP, so I don't think it's possible that I am missing a link to any libraries.
Although, I may try to rebuild Mixer-X after changing the order of things in my PATH variable since, looking back at the build log for Mixer-X and it was searching for libraries to use for the libXMP module, it found xmp.lib
from a prebuilt binary of Mixer-X instead of libxmp-static.lib
from my build of AudioCodecs. It makes sense that the library link would be missing, as I haven't linked any libraries from said prebuilt binary. I have doubts however since Mixer-X found libraries from both places for FluidLite.
Well, it used only the libraries from my AudioCodecs build for all modules, unfortunately the one exception being the problematic libXMP module I guess the problem stems from xmp.lib being somehow different from libxmp-static.lib, other than one being static and the other not? If so, this problematic usage of a different build's libraries makes more sense. Mixer-X possibly depends on the PBB's xmp.lib and couldn't work with AC's libxmp.lib.
Off Topic:
A tip: how to NICELY print long text pastas, use triple ```
. First one should take a whole line, and last too:
example
of
long
text
And how it looks:
Nope, copying the xmp.lib into the library directory and adding it into the linker didn't work, still same error I'm going to try something. I can change the file extension of the PBB's library to something like "bruh" so it can't be found, then change the name of the AC's library to xmp.lib for a chance of it being recognized. It doesn't really matter if the latter doesn't work, as long as the former does. In that case libXMP would be disabled, meaning no references to it in the newly built MixerX meaning that the linking problem surrounding libXMP would most likely cease to exist.
Ok I had to disable libXMP, now the count is shortened to 6 unresolved externals
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutOpen referenced in function init_midi_out
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutClose referenced in function close_midi_out
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutPrepareHeader referenced in function rtSysEx
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutShortMsg referenced in function update_volume
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutLongMsg referenced in function rtSysEx
1>SDL2_mixer_ext-static.lib(music_nativemidi_alt_win32.obj) : error LNK2019: unresolved external symbol __imp_midiOutReset referenced in function reset_midi_device
Would you happen to know where __imp_midiOut comes from?
This is WinAPI's winmm.lib
, you should link it.
OK now I can finally do the thing that required an entire 20 comments Test the WAV
OK now my entire "Doesn't Work" folder works with the only exception being the C64 SID dump (pretty reasonable, I tried out the singular library I found for it (libsidplayfp) and after looking at the code for the demo player's way of setting up, the library looked very ridiculous and full of redundancy to me.) Edit: I just found out that this support was requested 2 years ago #43
To close this issue once and for all, now all my WAVs work. The GarageBand WAV in this issue, and my two WAVs using the IMA ADPCM and Microsoft ADPCM format.
The ADPCM stuff I backported from SDL3 Mixer thing (it doesn't appears in SDL2 Mixer). So, have fun! :)
OH!!! I forgot to tell about libXMP, you are required to specify the -DLIBXMP_STATIC
macro in your project when linking the static libxmp build. It's because of the architectural mistake in the public header to use th edllimport
thing. It's totally NOT suggested to do for crossplatform libraries that designed to support both static and shared builds.
I had even reported about that: https://github.com/libxmp/libxmp/issues/427
So, to DON'T use dllimport()
in public headers, it makes almost no sense (only very small boost on loading of the project that links the shared library), and adds a lot of pain to people who attempts to use the library as a static one.
(Mainly, the MixerX itself do uses the libXMP, and MixerX already defines the -DLIBXMP_STATIC
inside self)
Done, https://github.com/WohlSoft/SDL-Mixer-X/commit/5b39283ff1895851c662e1a032af15b900ae6f98, I fixed the thing, now libxmp should link normally.
In SDL2_Mixer the file plays fine, but SDL-Mixer-X gives
Unrecognized audio format
I have linked the problematic .wav file here The only difference it has from a regular WAV file is that the header hasWAVEJUNK
instead ofWAVEfmt
When I changeWAVEJUNK
toWAVEfmt
the error becomesUnknown WAVE data format
It might be useful to know that the file was exported with iOS GarageBand