Jump to content

  • Log In with Google      Sign In   
  • Create Account





more fixed-block audio...

Posted by BGB, 04 May 2013 · 481 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.




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.

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.

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.

PARTNERS