Jump to content
Sign in to follow this  
  • entries
    37
  • comments
    37
  • views
    37363

more fixed-block audio...

Sign in to follow this  
cr88192

950 views

not much new here...

posted a simple comparison video (shows a few songs in their original forms vs after being fed through my codec):


as well as creating an area on my Wiki for information about the format:
http://cr88192.dyndns.org:8080/wiki/index.php/BGBTech_Audio_Codec

recently improved the handling of stereo, as-in, now it is a little less broken.
audio quality is a little harder of an issue, but it seems usable...


to some extent, support for this has been added to my existing mixer, but I am tempted partly to go and work on writing a more advanced mixer, mostly for procedural audio tasks (the basic idea is to have a mixer API sort of like GLSL, basically where samples are treated as samplers, ...).

while this isn't necessarily the most efficient way to handle mixing, it should be a little more convenient/flexible than the current strategy (basically, working with sounds directly in terms of arrays of samples), but I may need to try it out.
Sign in to follow this  


3 Comments


Recommended Comments

Sounds pretty good, based on the bitrates you posted earlier. It would be interesting to hear a recording of something sonically detailed with more varied dynamic range like a voice, acoustic instrument, or live orchestra.

Share this comment


Link to comment

in my tests thus far, voices usually come out a lot better.

 

I have not really tested it with orchestral pieces...

 

 

it actually does a pretty good job with Skrillex songs as well, and is fairly ok for a lot of Yoko Kanno music.

 

ironically, a song I have where it seems a bit weaker is actually one done in a retro/"chiptune" style. it messes up pretty bad in a few places and I am left wondering if there is an integer overflow somewhere or something (most of the codec is based on fixed-point integer math). (the RMSE for this song is fairly low, so "theoretically" it is working well..)

 

 

to some extent, the quality level is mostly due to the available block formats, with the encoder basically trying out different strategies (for each block of samples) to try to find the one with the least error (mostly minimal RMSE, but it also tries to estimate noise/pops as well). a lot of the block types were created experimentally, where ones which worked better were kept, and ones which were "generally worse" were dropped, ...

 

if only a single block-type is used, typically the audio quality will be lower, but the encoder can be faster.

 

also the quality is a little higher for songs with less left/right divergence, partly as stereo and mono quality are competing factors.

Share this comment


Link to comment

FWIW: I have implemented audio codecs in the past, but most were Huffman-coded ADPCM variants (with tunable quantization factors). a lot of these aimed for very low bit-rates, but also had poor quality. in my case, these lost out with me mostly opting with Ogg/Vorbis instead.

 

the main reason I had considered the newer codec was mostly for sake of random access.

also partly because I wasn't aware of anything similar existing.

 

I was partly thinking about how DXT gave surprisingly good results for how it worked (for texture compression), and considered trying out something similar.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!