Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » .VOC (Creative Voice File) samples playback with Allegro

This thread is locked; no one can reply to it. rss feed Print
.VOC (Creative Voice File) samples playback with Allegro
pkrcel
Member #14,001
February 2012

Hi guys,
I was looking at a way to load samples in the format cited in the thread title.

To my understanding, the 8bit unsigned PCM and 16bit signed PCM encoding could potentially be translated in a wave format with little effort, but what about the other (Soundblaster specific IIRC) codecs?

Better yet, is there out in the wild a library that can decode these and either let me load the sample data directly in Allegro or at least convert them into WAV (which I would write into a memfile and load then as samples?).

I've tried to scour the net for info but these are pretty obscure and I need some pointers (aha) for help.

Thanks for any suggestion & help.

Cheers
Pkrcel

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Chris Katko
Member #1,881
January 2002
avatar

Wow, you weren't kidding, that stuff was hard to find. Only thing I found worth note is this from 1999:

http://www.codeguru.com/cpp/g-m/multimedia/audio/article.php/c1563/VOC-File-Player.htm

What is this going to be used for?

Does it need to be run-time (can't convert beforehand)?

What operating systems are you targeting?

[edit] SDL Sound supports VOC and it's open source, so that is probably your best bet for modern running code. Especially seeing as how VOC has been depreciated for 20 years or so. Here's the patch where they added support, though they likely changed it since then.

[edit 2]

Here's some useful links:

The Creative Voice Format

A decoder in C++ - It dumps straight to a SB16, I think, but it's code that processes the file format, so that's the closest I've gotten so far.

If you want concise code, it looks like you'll have to roll your own from pieces. But if you don't mind the bloat of another library, through SDL in there and be done with it.

[edit 3]

BINGOOOOOOOOOOOOOOOOOOOOOOOOOO

libsndfile. I'm going to have to remember this for future use.

Quote:

Libsndfile is a C library for reading and writing files containing sampled sound (such as MS Windows WAV and the Apple/SGI AIFF format) through one standard library interface. It is released in source code format under the Gnu Lesser General Public License.

I just hope you're using a good operating system because it appears Windows isn't directly supported. ;)

[edit 4]

If you NEED windows and don't need to convert but just play those VOC files, here's one that supports Windows as well as Linux. It also does module files! But this library looks to be bigger and more intrusive since it plays the files as opposed to convert them. It's also only free for non-commercial applications.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

pkrcel
Member #14,001
February 2012

I went here to teel tha I found lisndfile myself but Chris beat me to it. ;D

Thank you so much for your effort tough, my google-fu was probably drained trying to find wildmidi for the Miles XMIDI decoding. :P

Anyway It seems that I should answer at least part of your questions:

What is this going to be used for?

I'm writing an LBX Handler targeted a Master of Orion, to be able to extract and convert on the fly resources from the original LBX files to memory to be later used by an Allegro engine.

I mean an engine for a rewrite from scratch of that very game...it's my big dream and I am trying to use the motivation as an excuse for doing stuff and learn something about C++ - Allegro and whatever comes under the radar doing that.

The choice not to convert the original data files beforehand (which could be done in the same way using the same approach but "on disk") is to conform to the choice of most of the "Openwhatever" modern day remakes that so can be distributed w/o thinking too hard about distributing copyrighted resources.

It is also an interesting problem to solve for a n00b like me. ;D

Bitmaps should be easy enuff to handle because with Allegro one has direct access to the bitmap's pixels so the decoding algorithm (which has been widely teared apart from enthusiast) can be applied directly.

For sounds, MOO uses straight VOC files for SFX and Miles Design AIL 2.0 Extended MIDI files.

For the latter I found both the open source AIL 2.0 from John Miles and an implementation of WildMIDI lib that could be used and saves meself from writing a decoder myself.

The idea is that I'll decode them into WAV memfiles and play/stream using Allegro Sound subsystem.

The daring could hope to add proper decoders to the Allegro acodec addon but I ain't up to the task.

Surely it will take a long time, but who knows...I might be hit by the Programmer's muse and code away my evenings for the years to come.

Quote:

I just hope you're using a good operating system because it appears Windows isn't directly supported

I am on windows but use MSYS2 shell, anyway libsndfile seems to be tested on both Win32 and win64:

Quote:

At the moment, each new release is being tested on i386 Linux, x86_64 Linux, PowerPC Linux, Win32 and Win64.

Finally

Quote:

But if you don't mind the bloat of another library, through SDL in there and be done with it

I will surely need at least a couple libs here and there so I'll have to live with it, but of course I wouldn't have used SDL, and most prolly would resolve myself into writing a decoder based on sox or the C++ decoder you linked (that was the only thing I didn't find of all your list....internet searching is REALLY an hard-to-master skill!).

By the way, since I am using MSYS2 seems libsndfile come at zero cost since it's in the mingw-w64 packages. SPOT ON! 8-)

Hope to make something out of all this mess! :o

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Gideon Weems
Member #3,925
October 2003

pkrcel said:

I'm writing an LBX Handler targeted a Master of Orion, to be able to extract and convert on the fly resources from the original LBX files to memory to be later used by an Allegro engine.

That is awesome. Are you contributing to FreeOrion?

I seem to remember having an old, SoundBlaster's programming manual (awesome, I know) at my parent's place (not awesome, I know). It's as thick as an unabridged Webster's. I'll try to dig it up on my next visit.

pkrcel
Member #14,001
February 2012

Are you contributing to FreeOrion [www.freeorion.org]?

Nope, did never dig the Freeorion project a lot to be frank.

Quote:

It's as thick as an unabridged Webster's

I remember most of my 8-bit era programming manuals that were this thick, too bad I was too darn young to understand fully those pesky schematics. :P
I also think that there were times were assembly code and good typography fought one big war.

On the other hand, I'm scouring through the docs (thin thin docs) of libsnd file and seems to me that it could not be all that difficult to use it for my needs.

While we're at it, I've also dived into the allegro_acodec addon files, and seems that a basic <format> driver should provide capability to just load the samples in memory into an ALLEGRO_SAMPLE, so if any dev could answer...how should one do that in a considerate way?

BUMP

Victory, I added supportfor Creative voice File through use of libsndfile in Allegro.

I'll prepare a pull-request on the github mirror for proper peer-review when I get the chance (I'm quite busy today :P )

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Polybios
Member #12,293
October 2010

Allegro 4 can read .voc files.

/* load_voc_pf:
 *  Reads a mono VOC format sample from the packfile given, returning a
 *  SAMPLE structure, or NULL on error. If successful the offset into the
 *  file will be left just after the sample data. If unsuccessful the offset
 *  into the file is unspecified, i.e. you must either reset the offset to
 *  some known place or close the packfile. The packfile is not closed by
 *  this function.
 */

Arthur Kalliokoski
Second in Command
February 2005
avatar

I just spent two minutes googling it and found this:

http://wiki.multimedia.cx/index.php?title=Creative_Voice

They all watch too much MSNBC... they get ideas.

pkrcel
Member #14,001
February 2012

Created pull request #10 ;D

This is mainly to let Siegelord know I have seen his suggestion to create the pull request to not have the thing buried in the forums :P

Can be closed anytime afterall ;D

I just spent two minutes googling it and found this:

well DUH! ...I also found that in my firsts search result, but I was also specifically asking for help in finding something that already decoded that :P

Polybios said:

Allegro 4 can read .voc files.

Ah yes, I forgot to mention this along with the code for SDL 1.3 which later also Katko pointed out.

I wrote this also in the pull request, I used an exernal decoder to ease the burden on ME, but would Allegro be better off with an internal one? I was under the impression that the only "wanted" native decoder was for wav and the others "should" depend on something external.

Re-reading this I wonder WHY I was under this impression.

Anyway this now work for ME yay! so I can go on with the project.

Can anyone tell me how to proper format a patch to be sent to the mailing list? ahem, n00b question :-[

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

pkrcel
Member #14,001
February 2012

MEH! I didn't think to look there >.<

Anyway this makes one patch for EACH commit, so it works for my latest commit if done right as listed, but NOT as like the pull request (I had 3 commits in there, and once merged they are in-between the latest ones by Trent and SiegeLord.

I resolved myself doing somethin like:

$> git diff -p upstream/5.1 > patch.diff

which might do the trick, at least I hope...of course I botched the filename. :-X

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Chris Katko
Member #1,881
January 2002
avatar

I just spent two minutes googling it and found this:

http://wiki.multimedia.cx/index.php?title=Creative_Voice

You mean my link at the top of this thread? :-*

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Arthur Kalliokoski
Second in Command
February 2005
avatar

You mean my link at the top of this thread? :-*

Well, yeah, I didn't read the thread carefully, and assumed that nobody had found a definitive description yet. It looks pretty straightforward to me except the alaw and ulaw stuff, I'd have to google awhile longer, but I doubt many VOC files used those anyway.

They all watch too much MSNBC... they get ideas.

Chris Katko
Member #1,881
January 2002
avatar

Almost definitely not used since that's for actual US/EU phone lines. They're a terrible encoding formats for anything except voice, and even then, the voices end up sounding like a phone call. So unless a game is going to add a separate encoder just to get phone effects, I think he'll be okay!

Additionally, those and 16-bit format were added later with the Sound Blaster 16 in 1992. Though, Masters of Orion came out 1993, so if they supported bleeding edge hardware 16-bit VOC's are still possible.

While reading some wikipedia on SB16 I found this interesting snippet:

Quote:

On many TEA2025-based boards, Creative used 47uF capacitors for the feedback and 1uF for the inputs, which should have been 100uF and 0.22uF respectively,[4] resulting in the amplified output having reduced bass and treble response. In addition, Creative used polarized capacitors where non-polarized capacitors should have been used, further degrading the amplified output's sound quality. On some cards (notably CT2770 cards) they also under-valued the capacitors for power regulators, which should be nominally 100uF.

On boards that use the TDA1517 amplifier, Creative used 470uF capacitors for the outputs where the TDA1517 datasheet suggested 1000uF, presumably to save money by using a common value across the range. Unlike the TEA2025, however, the TDA1517's datasheet called for polarized capacitors on the output.

Sound Blaster 16 sound cards built around the CT1747 chipset often have the internal gain set too high, causing clipping and crackling in the sound that wasn't present on sound cards built using the larger and less integrated CT1746B chip. This is most noticeable in the PCM sound output, which is still generated externally to the CT1747. The OPL-3 FM generally suffers much less from this, but there may still be occasional peaking when numerous loud tones are played simultaneously. Changing the mixer levels has no effect on the clipping; the only way to fix this would be to decrease the circuit's gain level.

I understand computer companies were more like garages back then than what we have today, but it's interesting to see how much they messed up simple component selection for their cards. I've got a degree in mechanical engineering, not electrical, but even I know how to read a datasheet and specify capacitors. :o The only saving grace (if you can call it that) is some insanely over-zealous part price reduction in which they said to "hell with the parts we actually need, get cheap ones that look the same."

Looking back on things, I never should have got my Audigy 2 ZX and went with something like M-Audio. They seem to have a history of being poorly put together, mislabeled (96 KHz! Downsampled to 48 KHz internally </whisper>), and definitely not long-term driver supported.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

pkrcel
Member #14,001
February 2012

Additionally, those and 16-bit format were added later with the Sound Blaster 16 in 1992. Though, Masters of Orion came out 1993, so if they supported bleeding edge hardware 16-bit VOC's are still possible.

Oh c'mon, of course they are all mono channel 8bit unsgined PCM data ;D

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

Well I don't mind adding support for another sound file format but I'd prefer the old allegro 4 loader to be ported to Allegro 5 in stead of libsndfile. I'm not too cool with GPL dependencies... VOC is a very simple format so writing a driver should be not too hard anyway...

pkrcel
Member #14,001
February 2012

Yeah, that's what I was mainly worried about, LGPL makes things a bit wonky for Allegro, since if I got it right dynamic loading of external libs is possible only on Windows?

By the way....this seems a right moment to ask "why is that?" I unfortunately am no Linux developer (yet) so can't tell why you can use the same approach on Linux.

Also, I guess that I can easily circumvent the problem having my engine use the shared version of libsndfile and have it write to a memory buffer; this can then be passed to a proper al_create_sample.

Well actually EXACTLY as it is in the current voc loader :P , only "not in Allegro"

It is improper also to call it a voc loader BTW, right now it is called on ".voc" extensions, but it could just as easily called on all libsndfile supported formats.

BTW:
I'm about to do something similar with WildMIDI for the XMIDI format from Miles Design. That has been put in the public domain (up to AIL 2.0) so going the WildMIDI route serves me only to ease my way in, but drags in the SAME LGPL wonkyness.

It's a nice proof-of-concept and a good way for me to hack into Allegro and get my feet wet, even thou these will be rejected.

EDIT:

I also found the soundblaster's original description of the format. I might try to stab a proper C decoder for fun.

Not that SoX or the other sources were incomplete but still this is charming :P

http://pdos.csail.mit.edu/6.828/2007/readings/hardware/SoundBlaster.pdf

EDIT2:

Pull request #10 has been updated with the internal VOC loader. I'dl ike to know if to make it pullable I shall remove the sndfile implementation altogether.

;D

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

Well that's already better, an internal voc decoder that doesn't need any external libraries is a nice extra feature for loading those old samples! I guess it will need a bit more polishing and the removal of libsndfile to make this more acceptable.

pkrcel
Member #14,001
February 2012

sndfile is a separate things altogether which can be removed at will ( I can commit the removal if that's ok, but I guess that should be in the Pull Request discussion?).

I've seen there are also LOT of warnings which I should remove (which C standard do we comply with in Allegro? C90 or C99?)

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

C90, since MSVC is dumb about C99.

pkrcel
Member #14,001
February 2012

Okay, I pushed the removal of SNDFILE support to the Pull Request.

I'll try to polish the code at best of my possibilities (which are limited ;D ), suggestions and (more even) critics are very welcome.

EDIT: pushed the cleanup to the PR. Awaiting feedbacks if any.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

The following files still show traces of libsndfile and shouldnot be modified.

cmake/FindSndfile.cmake
addons/acodec/allegro5/internal/aintern_acodec_cfg.h.cmake

The voc file loader itself looks OK for a first implementation. If anyone cares about the other types of voc files or data blocks then they can build upon this later. Jut fix the files mentioned above and I think you've got worth discussing on the mailing list. :)

pkrcel
Member #14,001
February 2012

I thought I already did remove those, I'll check better.

EDIT: I clearly forgot to remove the findSndFile cmake module, but I was pretty sure that aintern_acodec_cfg.h.cmake was rolled back. Oh git n00bishness! ;D

Pushed the fix to PR#10

beoran said:

The voc file loader itself looks OK for a first implementation. If anyone cares about the other types of voc files or data blocks then they can build upon this later. Jut fix the files mentioned above and I think you've got worth discussing on the mailing list. :)

The current loader should support up to version 1.20 of the specs and I couldn't find any upper spec.
What is unsupported compared to sndfile is the CIITT uLaw and A-law codecs which I guess we will not need to decode anytime soon.

Creative Adaptive PCM codecs aren't documented and are HW bound, so I guess these might prove to be a problem in the future.

The other block types might be supported but no one of them is relative to sound playback OR might be only implemented in Hardware as it was on the SB Card (how can you have a block repeat/end repeat sequence that supports endless loops? seems too much to care for extracting consistent PCM data).

Thanks for your comments, I'll try to send this again to the mailing list.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

SiegeLord
Member #7,827
October 2006
avatar

What's the status of this? Is it good to go?

EDIT: I've added some comments: https://github.com/liballeg/allegro5/pull/10

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

pkrcel
Member #14,001
February 2012

Thanks for the comments, I'm travelling in these days but I'll try to get on it as soon as I get back.

BUMP

Just pushed latest commits, hope these make it conformant to Allegro's style and practices.

Sorry for being a n00b, of course ;D

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Go to: