Switch Linux/Dolphin MP3 decode from minimp3 to libmad

minimp3's sliding-window frame confirmation could spuriously discard real
frames near the tail of a not-yet-full window, losing ~5.5% of a real
VBR file's content even at a tuned 256KB window (~0.3% residual) -
audible as the whole track finishing early with stutters at each drop.

libmad's mad_stream/mad_frame/mad_synth API reports "need more data"
(MAD_ERROR_BUFLEN) and "genuinely bad data" separately rather than
overloading one return value, which was the actual ambiguity minimp3
couldn't resolve. Verified against the same real file with a 32KB window
(vs minimp3's 256KB): frame count and duration match the Xing header
exactly. Confirmed building for Linux, GameCube, and Wii (the latter two
via the project's real devkitPPC/libogc Docker toolchain) - libmad ships
inside libogc itself on Dolphin, no separate fetch needed there.

libmad is GPL-licensed, unlike the rest of this MIT project - a
deliberate tradeoff, noted at each site that pulls it in.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

src/duskdolphin/audio/CMakeLists.txt

@@ -12,17 +12,13 @@ target_sources(${DUSK_LIBRARY_TARGET_NAME}
 
 # No hardware MP3 decoder used on Dolphin (see audiostreammp3decoder.h's
 # own comment on why libogc's MP3Player wrapper isn't a fit) - use the
-# same shared minimp3-based software backend as Linux, sourced directly
+# same shared libmad-based software backend as Linux, sourced directly
 # from src/dusk/audio rather than through its own unconditional
 # CMakeLists.txt so platforms with a hardware decoder (PSP) never pull
-# minimp3 in at all.
-if(NOT minimp3_FOUND)
-  find_package(minimp3 REQUIRED)
-endif()
-# PRIVATE to match this toolchain's own convention (see cmake/targets/
-# dolphin.cmake) of avoiding PUBLIC library visibility, which has tripped
-# up the PPC linker for other dependencies in the past.
-target_link_libraries(${DUSK_LIBRARY_TARGET_NAME} PRIVATE minimp3)
+# libmad in at all. Unlike Linux, libmad here comes bundled with the
+# devkitPPC/libogc toolchain itself (see cmake/targets/dolphin.cmake's
+# own "mad" link entry) rather than via find_package() - unnecessary
+# for, and not reliable when cross-compiling.
 target_sources(${DUSK_LIBRARY_TARGET_NAME}
   PUBLIC
     "${DUSK_SOURCES_DIR}/dusk/audio/stream/audiostreammp3decodersw.c"

src/duskdolphin/audio/audiostreammp3decoder.h

@@ -11,6 +11,9 @@
 // architecture (libogc's MP3Player wraps libmad but drives its own
 // internal audio output, bypassing the ansnd-based pipeline
 // audiostreamdolphin.c already owns - not a fit here), so Dolphin uses the
-// same shared minimp3-based software backend as Linux - see that header's
-// own documentation for the actual struct/interface.
+// same shared libmad-based software backend as Linux, driven directly at
+// the mad_stream/mad_frame/mad_synth level instead of through MP3Player -
+// see that header's own documentation for the actual struct/interface.
+// Conveniently, libmad ships as part of libogc itself (gc/mad.h) rather
+// than needing to be fetched separately, unlike on Linux.
 #include "audio/stream/audiostreammp3decodersw.h"