[Semi unmaintained] Dynamic Universal Music Bibliotheque - DUMB - Module/tracker based music format parser and player library -- Please consider using libopenmpt instead of this, it's considerably faster and produces similar or better rendering quality
License: Other
I know that 2GB-MOD-files are very unlikely to occur, but I am wondering whether it makes sense to support files >2GB.
I propose the following
-D_FILE_OFFSET_BITS=64 during build and ftello returns a 64-bit-type on 32-bit Unix-platformsDUMBFILE_SYSTEM to take DUMB_OFF_T which resolves to a 64-bit-type (can be checked at compile-time)What do others think?
Both alex4 and kraptor crash at approximately the same place. alex4 crashes right at the start, while kraptor crashes once you start a new game.
I guess, it is related to packfiles/datafiles reading. open-invaders which is another allegro4-game works fine, but it does use separate mod-files, which (I assume) is why it does not crash.
Backtrace is from my Debian-system, but it has been reproduced on Arch as well.
More investigation is needed. The double-free is in an error-handling path from allegro4, but something has gone wrong before, which is the actual reason. More analysis is needed.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff72d542a in __GI_abort () at abort.c:89
#2 0x00007ffff7311c00 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff7406d78 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff7317fc6 in malloc_printerr (action=3, str=0x7ffff7406eb0 "double free or corruption (top)",
ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049
#4 0x00007ffff731880e in _int_free (av=0x7ffff7638b00 <main_arena>, p=0x5555557b9110, have_lock=0) at malloc.c:3905
#5 0x00007ffff767c67f in load_file_object (f=f@entry=0x5555557b6000, size=size@entry=0) at ./src/datafile.c:1351
#6 0x00007ffff767c770 in load_datafile_callback (filename=<optimized out>, callback=0x0) at ./src/datafile.c:1397
#7 0x0000555555562e3e in init_game (map_file=0x55555556b121 "maps from datafile please") at main.c:730
#8 0x0000555555556e43 in main (argc=1, argv=0x7fffffffe028) at main.c:3091
foo_dumb v2.0.3
foobar2000 v1.4 and 1.4.1
I'm not sure this is the right place to report this, but I'll try.
Foobar2000 always crashes during playback at the end of this file:
ASIKWUSpulse - Shrubbing.s3m
I got the file from example songs distributed with OpenMPT editor, which plays it fine.
There seems to be some weird effect at the end, which prolongs a short sample to sound like a tape reel rolling to stop for some seconds. But what can be heard in fb2k at that place is several seconds of silence and then one short melodic "ping" sound right before crash.
Unrelated note: Skip Silence DSP jumps through the silent part quickly to the "ping", but does not cause or affect the crash.
Windows Error Report attached:
Report.wer.txt
Edit: PR #58 has a patch for this.
When I build DUMB master 6e924e6 with gcc version 7.2.0 in release mode, the build is error-free, but still shows the warning below.
Unfortunately, dumb_resample is long and nasty to read, therefore I haven't investigated further.
[ 19%] Building C object CMakeFiles/dumb.dir/src/helpers/resample.c.o
In file included from /home/simon/c/notown/dumb/src/helpers/resample.c:162:0:
/home/simon/c/notown/dumb/src/helpers/resamp3.inc: In function ‘dumb_resample_1_1’:
/home/simon/c/notown/dumb/src/helpers/resample.inc:134:72: warning: ‘volr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define RETURN_MONO_DEST_VOLUME_VARIABLES if ( volume ) volume->volume = volr
^
/home/simon/c/notown/dumb/src/helpers/resample.inc:117:41: note: ‘volr’ was declared here
#define MONO_DEST_VOLUME_VARIABLES vol, volr, vold, volt, volm
^
/home/simon/c/notown/dumb/src/helpers/resamp2.inc:93:26: note: in expansion of macro ‘MONO_DEST_VOLUME_VARIABLES’
#define VOLUME_VARIABLES MONO_DEST_VOLUME_VARIABLES
^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/simon/c/notown/dumb/src/helpers/resamp3.inc:50:8: note: in expansion of macro ‘VOLUME_VARIABLES’
float VOLUME_VARIABLES;
^~~~~~~~~~~~~~~~
In file included from /home/simon/c/notown/dumb/src/helpers/resample.c:183:0:
/home/simon/c/notown/dumb/src/helpers/resamp3.inc: In function ‘dumb_resample_16_1_1’:
/home/simon/c/notown/dumb/src/helpers/resample.inc:134:72: warning: ‘volr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define RETURN_MONO_DEST_VOLUME_VARIABLES if ( volume ) volume->volume = volr
^
/home/simon/c/notown/dumb/src/helpers/resample.inc:117:41: note: ‘volr’ was declared here
#define MONO_DEST_VOLUME_VARIABLES vol, volr, vold, volt, volm
^
/home/simon/c/notown/dumb/src/helpers/resamp2.inc:93:26: note: in expansion of macro ‘MONO_DEST_VOLUME_VARIABLES’
#define VOLUME_VARIABLES MONO_DEST_VOLUME_VARIABLES
^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/simon/c/notown/dumb/src/helpers/resamp3.inc:50:8: note: in expansion of macro ‘VOLUME_VARIABLES’
float VOLUME_VARIABLES;
^~~~~~~~~~~~~~~~
In file included from /home/simon/c/notown/dumb/src/helpers/resample.c:190:0:
/home/simon/c/notown/dumb/src/helpers/resamp3.inc: In function ‘dumb_resample_8_1_1’:
/home/simon/c/notown/dumb/src/helpers/resample.inc:134:72: warning: ‘volr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define RETURN_MONO_DEST_VOLUME_VARIABLES if ( volume ) volume->volume = volr
^
/home/simon/c/notown/dumb/src/helpers/resample.inc:117:41: note: ‘volr’ was declared here
#define MONO_DEST_VOLUME_VARIABLES vol, volr, vold, volt, volm
^
/home/simon/c/notown/dumb/src/helpers/resamp2.inc:93:26: note: in expansion of macro ‘MONO_DEST_VOLUME_VARIABLES’
#define VOLUME_VARIABLES MONO_DEST_VOLUME_VARIABLES
^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/simon/c/notown/dumb/src/helpers/resamp3.inc:50:8: note: in expansion of macro ‘VOLUME_VARIABLES’
float VOLUME_VARIABLES;
^~~~~~~~~~~~~~~~
In old dumb 0.93 I have had executables
/usr/bin/dumb2wav
/usr/bin/dumbout
/usr/bin/dumbplay
And now are only
Linking C static library libdumb.a
cmake/libdumb.a
How to build in?
dumb/src
dumb/src/ > make
make: *** No targets specified and no makefile found. Stop.
Please make these executables and
cmake/libdumb.so
Public dumb.h unconditionally redefines MIN, MAX, MID, ABS. I am wondering what the reason for this is. I think it should go under include/internal.
Or is there any reason why a user of DUMB might need those macros? If there is such a reason, they should probably be prefixed.
When using "Use playptmod or modplay" DUMB can't go pass 0:19 of this song. Disabling "Use playptmod or modplay" fixes issue.
Upstream issue?
ftp://modland.ziphoid.com/pub/modules/Protracker/Nightlight/dirt.mod
http://janeway.exotica.org.uk/release.php?id=32999#downloads
https://www.dropbox.com/s/6ahm17y6oyxtgln/DIRT.MOD?dl=0
I have a few PSM modules in my collection and I noticed with DUMB 2.0 that these had garbled audio (they didn't with earlier versions). I found the issue was with a flags variable being used without being initialized. I've attached a patch that addresses the issue.
The 1.0 release is over two years and a half old at the time of this writing. Since then, there have been various fixes and improvements which are useful to Linux distros, e.g. Allegro 4 support. And usually, distros would rather package releases than versions directly from the SCM :)
Before making a release, maybe the README should be updated to mention the new capabilities of this continuation of the original DUMB library still available from SF.net ?
The license in this fork doesn't seem to include the clause 8 added later by the original author of libdumb (see: http://dumb.sourceforge.net/index.php?page=licences). With that clause, the license would be pretty much BSD. Without it, the package is kind-of-maybe-non-free. Should this fork include it ?
Also, since this fork is now pretty much the official package (See first news entry in http://dumb.sourceforge.net/), would it be possible to get a new release (0.9.4) ? :P That way it would be possible to get eg. debian to dump an updated libdumb package out.
After commit 6b24397 I got this error:
[ 1%] Building C object CMakeFiles/aldmb.dir/src/allegro/packfile.c.o
/home/winterheart/playground/dumb/src/allegro/packfile.c: In function 'dumb_packfile_open_ex':
/home/winterheart/playground/dumb/src/allegro/packfile.c:38:28: error: 'filename' undeclared (first use in this function)
file->size = file_size_ex(filename);
^
OS: Debian testing
Arch: amd64
I noticed that dumb_read_mod fails when called with DUMB_MOD_RESTRICT_OLD_PATTERN_COUNT and the attached mod-file from the game Alex the Allegator 4.
alex4_once_i_was_an_egg.tar.gz
DUMBFILE *df = dumbfile_open_stdfile(fopen("./alex4_once_i_was_an_egg.mod", "rb"));
DUH *duh = dumb_read_mod(df, DUMB_MOD_RESTRICT_OLD_PATTERN_COUNT);
fprintf(stderr, "dumb_read_mod returned %p\n", duh);
dumbfile_close(df);
I tracked it down to a read past the end of the file here:
Lines 47 to 50 in 7415127
read of size 20 with 42792 bytes left
read of size 22 with 42772 bytes left
read of size 22 with 42742 bytes left
read of size 22 with 42712 bytes left
read of size 22 with 42682 bytes left
read of size 22 with 42652 bytes left
read of size 22 with 42622 bytes left
read of size 22 with 42592 bytes left
read of size 22 with 42562 bytes left
read of size 22 with 42532 bytes left
read of size 22 with 42502 bytes left
read of size 22 with 42472 bytes left
read of size 22 with 42442 bytes left
read of size 22 with 42412 bytes left
read of size 22 with 42382 bytes left
read of size 22 with 42352 bytes left
read of size 22 with 42322 bytes left
read of size 22 with 42292 bytes left
read of size 22 with 42262 bytes left
read of size 22 with 42232 bytes left
read of size 22 with 42202 bytes left
read of size 22 with 42172 bytes left
read of size 22 with 42142 bytes left
read of size 22 with 42112 bytes left
read of size 22 with 42082 bytes left
read of size 22 with 42052 bytes left
read of size 22 with 42022 bytes left
read of size 22 with 41992 bytes left
read of size 22 with 41962 bytes left
read of size 22 with 41932 bytes left
read of size 22 with 41902 bytes left
read of size 22 with 41872 bytes left
read of size 128 with 41840 bytes left
read of size 5 with 823 bytes left
read of size 5 with 3040 bytes left
read of size 5 with 6420 bytes left
read of size 5 with 8449 bytes left
read of size 5 with 8577 bytes left
read of size 5 with 8705 bytes left
read of size 5 with 8801 bytes left
read of size 5 with 8865 bytes left
read of size 5 with 8929 bytes left
read of size 1024 with 8940 bytes left
read of size 1024 with 7916 bytes left
read of size 1024 with 6892 bytes left
read of size 1024 with 5868 bytes left
read of size 1024 with 4844 bytes left
read of size 1024 with 3820 bytes left
read of size 1024 with 2796 bytes left
read of size 1024 with 1772 bytes left
read of size 1024 with 748 bytes left
dumb_read_mod returned (nil)
Hi there. I'm trying to compile this project on OSX (10.12.6), but I've got a bit of a weird setup. Allegro 4 cannot easily be compiled anymore on modern OSX, so I compiled a version using the OSX 10.4 SDK that will run on modern versions. (Last time I tried, the brew allegro4 install script was broken.)
Since I'm using this build of Allegro 4, I need to ensure that it can find the library and include files, which I currently do by configuring with: cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_ALLEGRO4:BOOL=ON -DALLEGRO_INCLUDE_DIR="/Users/msikma/liballeg.4.4.2-osx/include/" -DALLEGRO_LIBRARY="/Users/msikma/liballeg.4.4.2-osx/lib/liballeg.4.4.2.dylib" ..
However, as soon as the compilation reaches Allegro, it errors out:
/Users/msikma/Source/dumb/src/allegro/alplay.c:22:10: fatal error: 'allegro.h' file not found
If I run make -n to find the command it's trying to run, and manually add -I/Users/msikma/liballeg.4.4.2-osx/include to it, the compilation succeeds.
Is there any way I could add the passed ALLEGRO_INCLUDE_DIR to the compilation commands during generation? I'm not really very familiar with Cmake so any help would be appreciated...
From the feature list in the readme:
Option to take longer loading but seek fast to any point before the music first loops (seeking time increases beyond this point)
I can't figure out how to seek. I'm trying to add a button to my program to seek to the 0:00 mark (aka restart the song), but searching seek, rewind, restart, etc. in the source code doesn't reveal anything. If you have any notes on this, I'd very much appreciate it. Thank you!
Looks like the allegro libraries are gone. Are they not longer supported?
The check to see if a pointer is non-null before calling free can be safely omitted. For example, in _dumb_it_unload_sigdata of itunload.c
The restrict_ parameter could be documented better and one should probably avoid magic numbers and instead either define an enum or preprocessor-constants for the two values.
/* dumb_*_mod*: restrict_ |= 1-Don't read 15 sample files / 2-Use old pattern counting method */
DUH *dumb_load_mod(const char *filename, int restrict_);
DUH *dumb_read_mod(DUMBFILE *f, int restrict_);
DUH *dumb_load_mod_quick(const char *filename, int restrict_);
DUH *dumb_read_mod_quick(DUMBFILE *f, int restrict_);
DUH *dumb_read_any_quick(DUMBFILE *f, int restrict_, int subsong);
DUH *dumb_read_any(DUMBFILE *f, int restrict_, int subsong);
DUH *dumb_load_any_quick(const char *filename, int restrict_, int subsong);
DUH *dumb_load_any(const char *filename, int restrict_, int subsong);
If a user passes a sample bank, please support a combination of MIDI loading + SF2 {or any well used patch file format: DLS/PAT/DAT}.
Allegro 5 itself may not have a standard way to play MIDI anymore, so one would have to rely on functionality from DUMB.
I'm getting the following error on 32bit debian linux:
/home/tuomas/projects/dumb/dumb/src/it/itrender.c: In function ‘_dumb_init_sse’:
/home/tuomas/projects/dumb/dumb/src/it/itrender.c:754:5: error: inconsistent operand constraints in an ‘asm’
Maybe the linux default -fPIC doesn't like the CPUID code ?
Hey just wanted to report a build issue, I got to 97% and than ran into this build error
[ 97%] Building C object CMakeFiles/dumbout.dir/examples/dumbout.c.o
/home/corey/dumb/examples/dumbout.c:1:10: fatal error: argtable2.h: No such file or directory
1 | #include <argtable2.h>
| ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/dumbout.dir/build.make:76: CMakeFiles/dumbout.dir/examples/dumbout.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:141: CMakeFiles/dumbout.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
Hi, I have support for DUMB 1.0 in Allegro 5 while keeping its DUMB 0.9.3 support. To differentiate between 1.0 and 0.9.3, I use #if ((DUMB_MAJOR_VERSION) >= 1). This looks like the best way to handle the API breakage.
The Arch Linux DUMB package points to the commit tagged 1.0, it's good style to package only from tagged versions. Unfortunately, dumb.h in that commit still defines its version as 0.9.3.
Please increase 1.0.0 to 1.0.1 in the header, then tag that new commit as 1.0.1. If you prefer 1.1 or any other 1.y.z, that's perfectly fine, too.
@SiegeLord, Allegro 5 maintainer, agrees that such a new tag would be the best solution. I'll email the Arch DUMB and Allegro 5 package maganager afterwards and coordinate.
I was trying to add tracker module support to an internet music streamer project of mine, and found out that dumbout can't accept stdin or a URL as input.
I'm using libmodplug with ffmpeg for the time being and I'd really like to use DUMB instead.
Would it be possible to get a release tagged out ? Possibly dumb 0.9.4 or 1.0 or something ? That would make it easier to refer to the project and maybe package it for linux.
Currently the project has some unnecessary directories. Some thoughts:
Firstly, there is an extra "dumb" directory at the project root; moving everything from inside it to the project root might make it easier to browse things (one less click). Also, readme and other files would be available at project root, which seems to be the usual way to do things nowadays.
Also, moving VS and CMake project files to the root would clear out some extra directories, and eg. CLion IDE likes seeing cmakelists.txt in root. Not sure if moving the vc6 project would make sense, though.
Would these changes be acceptable if I made some commits ? :)
Hi. In the Ode:
https://modarchive.org/index.php?request=view_by_moduleid&query=84861
there's an interesting part at 20 seconds. Dumb decreases the volume (by my count) 8 times during that long sustained note that's part of the pattern loop. Other replayers (OpenMPT, Micromod) don't drop the volume there. XMPlay does... which behaviour is correct here, or is it a judgment call? Looking at the mod, I don't see how these volume steps are happening, so I'm surely missing something. Thanks!
File: http://www.lixgame.com/etc/basement.it -- from the soundtrack of the cancelled Jazz Jackrabbit 3. Most files of that soundtrack play perfectly in DUMB. This one file doesn't.
Issue manifests in a small Allegro 5 program that calls DUMB master (6e924e6) as dumb_read_any(file, 0, 0).
Issue manifests slightly differently in DeaDBeeF that uses the DUMB plugin, version 1.0. The plugin says: "(C) 2009-2014, uses a fork of DUMB, Version 0.9.3". The issue here is: The file isn't recognized as a playable file at all. DeaDBeeF says: playlist load fail (basement.it)! failed to add file or folder basement.it.
File plays normally in VLC.
Once upon a time, DUMB shipped with aldumb.h, libaldmb.so, and friends. I noticed none of these are included in your fork (which has been endorsed by DUMB's author) and was wondering if you believe responsibility for this functionality lies elsewhere (like the Allegro 4 library). As is, without any package providing these files, Alex 4 does not run--and that game is a classic. There are likely other affected applications, though I doubt many users have been affected yet, as a cursory search shows that only one major distro (Arch Linux) has adopted your fork as official. Anyway, thanks for keeping DUMB alive! It's important software.
There's another issue with dumb_off_t. On my 32-Bit Windows machine with MinGW, off_t is 32-bit so DUMB fails to compile.
You have your awesome DUMB 0.9.3 or DUMB 1.0 app, build it against DUMB 2.0, and everything crashes. What do you have to do?
Gist of the necessary doc:
DUMBFILE_SYSTEM needs 7 pointers instead of 5, and the signatures have changed. Look in include/dumb.h for a quick overview, and in DUMBFILE_SYSTEM.md for a more complete spec.dumb_off_t instead of long. Most of that is backwards compatible unless you have function pointers to these.Shortcomings of the 2.0 API:
DUH.length is dumb_off_t, but this is not the clearest type. It's good that this is 64-bit, but it doesn't measure disk file offsets. length measures the total time of the DUH in 65536-ths of a second, where a DUH is a format-agnostic abstraction of a tracked song.pos, and this is exposed in the API as long. It should ideally have the same type as DUH.length.What's the worst impact of these shortcomings? If your long is 32-bit (should only happen on Windows), your pos might be broken 2^15 seconds into a song, which is about 9 hours. It's really minimal impact, and this bug was already in DUMB 0.9.3. At best, it's sad that the 2.0 API isn't perfect. :-)
Thus, don't change anything in the 2.0 API. But let's point it out in the header, and document it in prose outside of the source.
(Ideally, for a theoretical 3.0 API in 5 years, both sigrenderer's pos and DUH's length should be of a new type struct dumb_time_t { int32_t frac; int64_t seconds; }, where the fractional part measures the 65536-ths of a second. Fixed-width integers. <3)
So, the current license has some problems.
I'd suggest changing to some generic license, but is that doable ?
I used Dumb for all sorts of modplug music including the original Unreal and Unreal Tournament but here it seems like Dumb can't handle the files.
The UMX files from the 1998 Beta of Unreal to be exact. There doesn't seem to be anything special about them. They are just like the UMX files from the 1999 released Unreal game, at least that is what I can make out. Modplayers such as OpenMPT also open the music but when I drag the UMX files into Foobar, it can't properly detect them whatsoever and converting them does nothing expect showing errors.
My guess is that this is probably one of the very first UMX file versions that was only used by the Unreal demos and betas which weren't for the public. Therefore Dumb hasn't been optimized for the files.
Could this be fixed? Dumb is a great and easy tool/plugin to extract this music and I absolutely love this music by Alexander Brandon and Michiel Van Den Bos. I would like to make a HQ Lossless version of the Beta soundtrack which has many exclusive tracks. Without Dumb I have to resort to other possibilities though which might not offer the HQ I desire and are a lot more complicated to use.
Here are 3 of the UMX files from the soundtrack. Maybe they help figuring out why it doesn't work.
The codebase has inconsistent indentation. Some parts use tabs, some parts use 4 spaces. Some files mix both wildly.
This is not urgent. Version 2.0 doesn't need consistent whitespace. But it's a nice guesture for future contributiors. Diffs will be cleaner, and pull requests will have a lower chance of stepping on each other.
For after 2.0, therefore, I propose:
After this conversion, if future PRs would introduce weird whitespace, ask pull requesters to fix their whitespace before the merge.
My personal style is 4 spaces, but only 20 % of DUMB is in that style, 80 % of DUMB is tab-indented. For fun: Tabs or spaces across repositories, where tabs, 2 spaces, and 4 spaces are almost equally popular across C projects.
Hello,
I just compiled allegro from source into /usr prefix on my slackware system; URL was:
https://github.com/liballeg/allegro5/releases/download/5.2.5.0/allegro-5.2.5.0.tar.gz
No errors were reported here during this step.
Now I try to compile dumb, this tarball release:
https://github.com/kode54/dumb/archive/2.0.3.tar.gz
But I get an error during cmake checking stuff:
cmake -DCMAKE_INSTALL_PREFIX=/usr/ /Depot/Temp/rbt/dumb-2.0.3/
-- The C compiler identification is GNU 9.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test CC_HAS_WNO_UNUSED_VARIABLE
-- Performing Test CC_HAS_WNO_UNUSED_VARIABLE - Success
-- Performing Test CC_HAS_WNO_UNUSED_BUT_SET_VARIABLE
-- Performing Test CC_HAS_WNO_UNUSED_BUT_SET_VARIABLE - Success
-- Performing Test CC_HAS_WALL
-- Performing Test CC_HAS_WALL - Success
-- Performing Test CC_HAS_GGDB
-- Performing Test CC_HAS_GGDB - Success
-- Performing Test CC_HAS_ZI
-- Performing Test CC_HAS_ZI - Failed
-- Performing Test CC_HAS_G
-- Performing Test CC_HAS_G - Success
-- Performing Test CC_HAS_MSSE
-- Performing Test CC_HAS_MSSE - Success
-- Compiling with SSE support
CMake Warning at cmake-scripts/Findargtable2.cmake:26 (message):
Could not find Argtable2
Call Stack (most recent call first):
CMakeLists.txt:59 (find_package)
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found SDL2: /usr/lib64/libSDL2.so;-lpthread
-- Looked for Allegro libraries named .
CMake Error at cmake-scripts/FindAllegro4.cmake:35 (MESSAGE):
Could NOT find Allegro library
Call Stack (most recent call first):
CMakeLists.txt:66 (find_package)
-- Configuring incomplete, errors occurred!
See also "/Depot/Temp/rbt/dumb-2.0.3/CMakeFiles/CMakeOutput.log".
See also "/Depot/Temp/rbt/dumb-2.0.3/CMakeFiles/CMakeError.log".
The first .log file reports strange errors such as:
/usr/bin/cc -Wall -Wno-unused-but-set-variable -Wno-unused-variable -O2 -fPIC -fno-strict-overflow -Wno-error -DCC_HAS_ZI -Zi -o CMakeFiles/cmTC_555bf.dir/src.c.o -c /Depot/Temp/rbt/dumb-2.0.3/CMakeFiles/CMakeTmp/src.c
cc: error: unrecognized command line option '-Zi'; did you mean '-Z'?
But I am not sure if these are the problems.
For some reason the cmake script can not find allegro.
I think some problem comes here:
-- Found Threads: TRUE
-- Found SDL2: /usr/lib64/libSDL2.so;-lpthread
-- Looked for Allegro libraries named .
It oddly enough looks at libraries named "." which perhaps means
that either it could not find anything at that spot; or it tried the
current working directory. I assume some substitution may happen
here that fails. GNU configure also sometimes behaved oddly in
some scripts, not sure. Anyway I report this here - perhaps it
does not work for others, perhaps it does. Perhaps the information
may be useful if someone finds some problem here - I am not
knowledgable enough about cmake to resolve this, but perhaps
a future release of dumb may fix these issues.
Among other things, this would allow for context-sensitive music in games (such as how the boss battle music in Skies of Arcadia goes from somber when the party is near death to triumphant when the enemy has very low health, the minor-key/'you lost all your gold' portion of the Pitfall theme, etc.)
A long time ago, I had a patch for this that compiled against 0.93; if this is a feature you'd be willing to accept, I can bring it up-to-date with the current codebase and make a pull request for it.,
Please accept this patch, thanks.
cat dumb-0.9.3-CVE-2006-3668.patch
--- src/it/itread.c
+++ src/it/itread.c
@@ -292,6 +292,11 @@
envelope->flags = dumbfile_getc(f);
envelope->n_nodes = dumbfile_getc(f);
+ if(envelope->n_nodes > 25) {
+ TRACE("IT error: wrong number of envelope nodes (%d)\n", envelope->n_nodes);
+ envelope->n_nodes = 0;
+ return -1;
+ }
envelope->loop_start = dumbfile_getc(f);
envelope->loop_end = dumbfile_getc(f);
envelope->sus_loop_start = dumbfile_getc(f);
Hello !
I'm a C programmer using Dumb for .it playback, i'm happy with its accuracy, but i have to admit, it's one of the dumbest (ahah) piece of code i've seen. Such a bizarre architecture with unoptimized algorithms and duplicated code everywhere.
I still wonder why the voices are mixed in that way:
Why don't use floats everywhere ? The conversion takes probably more time than the small speedup of int's
Also in the linear resampling algorithm, to keep the phase into 0...1 range you can simply do (phase-(int)phase) instead of fmod(phase,1) which is quite cpu demanding.
There is a bug in the channels and NNA channels numbers, if you set the #define channel_count (don't remember its exact name) to another value than 64 the program crashes, it's because the IT format uses a 64-element fixed size array for channel volumes/pans, disregarding the module's real channel count. You have to use 64 as fixed value when parsing the IT, then you can use the #define channel_count for mixing if you need for e :)
No offense, I really appreciate the overall work, having a pure C impulse tracker playback library that doesn't rely on 5000 dependencies is awesome.
I'd be happy to contribute to the project if you feel like me that some optimization isn't bad :)
When playing a module with my application that uses DUMB, my application kept crashing when trying to render the audio. I tracked the crash down into resampler_run_cubic_sse() in 'src/helpers/resampler.c'. Specifically, it crashes when calling _mm_setzero_ps().
I was able to work around the issue by setting USE_SSE to OFF when configuring the build options for DUMB.
I found this page which may be useful in solving the issue. My application spawns a thread to run the audio rendering code. I also tried using Allegro 5 and it has the same crash. Allegro 5's audio codec streamers use a separate thread as well.
I went ahead and built a single-threaded test application and it doesn't crash on the same code.
Line 98 of 'include/dumb.h' should be:
typedef DUMB_OFF_T_CUSTOM dumb_off_t;
not:
typedef dumb_off_t DUMB_OFF_T_CUSTOM;
I recently fuzzed the old libdumb from SF using afl-fuzz and the following simple client:
#include "dumb.h"
#include <stdio.h>
int main(int argc, char * argv[])
{
DUH * duh;
dumb_register_stdfiles();
duh = dumb_load_it(argv[1]);
if (!duh) {
duh = dumb_load_xm(argv[1]);
if (!duh) {
duh = dumb_load_s3m(argv[1]);
if (!duh) {
duh = dumb_load_mod(argv[1]);
if (!duh) {
fprintf(stderr, "Failed to load %s!\n", argv[1]);
return 1;
}
}
}
}
unload_duh(duh);
return 0;
}
I haven't rebuilt this strain of libdumb with afl instrumentation yet, or adjusted the above example to use the function which attempts to load any file, to see whether this strain of libdumb fares better than the original one. But the point of this issue is, maybe such a trivial client with zero sound setup and output capability (they only take time for a fuzzing workload aimed at exercising the file loading code) belongs upstream ?
Would it be possible to also distribute tarball-released versions of dumb/libdumb, sort of "stable" versions?
Something similar to https://github.com/wxWidgets/wxWidgets/releases/
Reason I ask is because my set of ruby scripts work a lot easier if they can just grab a tarball release. While it is possible to use git checkouts, I feel a lot more confident with tarball releases, largely because I am under the assumption that upstream developers make tarball releases better than casual git checkouts. :)
No matter open or add any module music, fb2k crash.
fb2k v1.3.14
Crash Report
Hi! I'm having an issue with the 2.0.2 version of the component and Foobar 1.3.17
Seems that some mods are added twice to the playlist, for example:
LIVING.zip
The MOD file plays OK, but since it is an old module from the DOS era that survived many HD, CAN have some kind of corruption in it. Anyway, perhaps some kind of extra-check while adding mods can be implemented to improve this?
Thanks!
There is a pile of deprecated functions, and have been since 0.9.3, Would it be time to drop them in 2.0.0 ?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.