Compiling Music and Other non-code Data into a Linux Executable
category: code [glöplog]
Hi, does anyone know how to compile music into a linux executable? I have been looking at http://xmp.sourceforge.net/ library for module playback but even if that works I would like to be able to compile the module files into a linux program similar to resources on vcpp.
Put the music/data file into a byte array (probably using something as binh2 - NOT TESTED - or write such a tool yourself, it's trivial), and pray that the library in question allows for memory files (dunno if xmp does, libbass certainly allows for file to be loaded from memory). If it doesn't, you could still write the byte array to a temporary folder and pass the temporary file to your library.
Why would you want to do that?
preacher: 64k? :)
come on, this is the demoscene... there is no "why" :)
srecord is also quite useful for generating binary chunks in various formats.
Or incbin it from a nasm file
or .incbin from a gas file
Gargaj: But then again, I'd guess that 64k and xmp wouldn't mix very well.
I still like things like
static const char myMusic[] = { 0x1f, 0x76, 0x1a, 0xff, 0xfe, .... };
It works in all operative systems/compilers
static const char myMusic[] = { 0x1f, 0x76, 0x1a, 0xff, 0xfe, .... };
It works in all operative systems/compilers
you can get the hex numbers to include from
Code:
xxd -i < your.file
What iq said. Adding that in 3 minutes you can code a little program that converts a file to it. But it does have problems with big files.
Btw if you have to use an external shared library, like xmp/whatever, please link it staticly, it will make your prod more portable. If it is for a size limited prod, there are some options with gcc to merge only symbols used from static library to your elf, by default, gcc will merge the entire object that contain your needed symbol into your elf.
I'll take this opportunity to rant a bit:
Not static const unsigned char []?
What's wrong with sizeof(foo)?
Quote:
bin2h bin2h.exe bin2h.h -nosize
This will create a file, bin2h.h, which defines a variable of type unsigned char [] named bin2h, but will not define the variable bin2h_size which would otherwise indicate the size of that array.
Quote:
unsigned char []
Not static const unsigned char []?
Quote:
bin2h_size
What's wrong with sizeof(foo)?
I'm not so fond of sizeof... imagine a function that expects an array of unsigned char, you'd write
At this point i'm not sure what sizeof() does with constant fixed-sized arrays, I've always gone the safe way by having a separate constant for the array size.
Code:
. If you then call sizeof(myArray) you'll get either 4 or 8, depending if you're targetting a 32 or 64 bit platform. sizeof() measures the size of the pointer, and doesn't tell you the real length of the array.void myfun(unsigned char* myArray) {}
At this point i'm not sure what sizeof() does with constant fixed-sized arrays, I've always gone the safe way by having a separate constant for the array size.
i was just thinking about this the other day, it's a bit sad that there's no intrinsic language construct for this kinda stuff in the C standard
tbh I don't think using strlen for such things seemed so nasty back in those days :)
Quote:
I'm not so fond of sizeof... imagine a function that expects an array of unsigned char, you'd write
Code:void myfun(unsigned char* myArray) {}
. If you then call sizeof(myArray)
You're doing it wrong. myArray is a pointer, not an array.
Quote:
you'll get either 4 or 8,
For certain implementations. In general you can actually get anything, as long as it's >= 1. But I digress.
Quote:
At this point i'm not sure what sizeof() does with constant fixed-sized arrays
sizeof returns the size of an array in bytes. Note that sizeof char == 1 by definition. A byte isn't necessarily eight bits.
Quote:
i was just thinking about this the other day, it's a bit sad that there's no intrinsic language construct for this kinda stuff in the C standard
Yes there is - it's called sizeof. But yeah, keeping the value around is a bit of janitorial work. This is necessary because otherwise you wouldn't be able to point inside an array and still be able to get its size (unless you waste space by putting the remainder's size between each element).
Stuff like this is what makes C so portable, as long as you know wtf you're doing :)
avoid long compilation times, and simply use objcopy to convert a binary file into an object-file with the needed symbols.
What kusma said, objcopy. Objcopy has the benefit of making binary objects directly and letting you choose the destination segment you want. This is immensly useful when you are linking in binary data for platforms like GBA,DS,etc where you have ROM and RAM sections of memory and don't want to waste ram on static data or want a table to reside in some fast memory. (Yes const data should be fine in most cases instead of objcopy)
http://stackoverflow.com/questions/4864866/c-c-with-gcc-statically-add-resource-files-to-executable-library Also check the objcopy manpages.
http://stackoverflow.com/questions/4864866/c-c-with-gcc-statically-add-resource-files-to-executable-library Also check the objcopy manpages.
Given that it seems my link was ignored I will point it out again.
The bin2h solution is quite nice portability wise (See below for a comment on that thing). But for huge resources kusma is totally right.
I would use the approach mentioned in the link I posted - if targeting linux.
Given that you are all very lazy here - again:
MyFile.foo is our music, resource - or whatever thing we want to have in the binary.
Now you can link with the incbin.o obj you just created and use the data with the help of the following nice symbols.
(Never heard of objcopy - is that he same thing?)
You could also generate a MyResource.c & MyResource.h pair and generate a object file from that - that could be a good compromise of "compile time friendliness" and portability.
The bin2h solution is quite nice portability wise (See below for a comment on that thing). But for huge resources kusma is totally right.
I would use the approach mentioned in the link I posted - if targeting linux.
Given that you are all very lazy here - again:
Code:
las@jumper$ ld -r -b binary -o incbin.o MyFile.Foo
las@jumper$ objdump --syms incbin.o
incbin.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 g .data 0000000000000000 _binary_MyFile_Foo_start
000000000000001a g *ABS* 0000000000000000 _binary_MyFile_Foo_size
000000000000001a g .data 0000000000000000 _binary_MyFile_Foo_end
$
MyFile.foo is our music, resource - or whatever thing we want to have in the binary.
Now you can link with the incbin.o obj you just created and use the data with the help of the following nice symbols.
Code:
extern const char _binary_MyFile_Foo_start[];
extern int _binary_MyFile_Foo_size[];
extern const char _binary_MyFile_Foo_end[];
(Never heard of objcopy - is that he same thing?)
You could also generate a MyResource.c & MyResource.h pair and generate a object file from that - that could be a good compromise of "compile time friendliness" and portability.
kb_ posted a tiny mod player in this thread
Here's the link to the source code
http://www.1337haxorz.de/drugs/tinymod.cpp
Here's the link to the source code
http://www.1337haxorz.de/drugs/tinymod.cpp