dBpowerAMP Development Diary

[Spoon]

The purpose of this sticky (which will grow over time) is to document (for you aswell as me) what is actively being developed, even to sometimes small detail. Certain items, which are deemed a competitive advantage will only become known once they are released to beta.

[Spoon]

Re: dBpowerAMP Development Diary

December 2005

dMC R12: Serious spade work has gone into dBpowerAMPs mp3 decoder, work includes (but is not limited to): gapless decoding (both from Lame tag and VBRI), which is sample perfect (a world first: first program I am aware that can decode Lame and FhG gapless). dBpowerAMP R12 has one of the most advanced mp3 decoders, featuring: gapless, decoding to various bit-depths, various types of dither (read on...), correct reading of VBRI, Lame Tag, Xing header, Info header, free format mp3 decoding. State of the Art.

ID Tags: the maze of tag types are being unravelled, priorities are Album art (compatible with major programs), preferences, times played, multiple Artists / Genres, replay gain. Each of these do not sound show stoppers on their own, but to preserve them across formats (ie ogg to mp3, note not replay gain) and even across programs (ie Music Match and iTunes are diffrenent beasts), that is the achievement. Put it this way, it would be 40x less work just to implement my own standards (I could name some names of culprits), but that achieves nothing.

Lets talk dither, dithering works by adding random noise when decreasing bit-depth, such as going from 24 bit to 16 bit, allowing low volume signals that would be normally decimated to still be present, whilst the random signal increases the noise floor it normally remains inaudible (I will update Spoons audio guide with technical details when have chance). There are many types of dither, simple rectangular where random noise (pure white noise) is added, Triangular Probability Desnisty Function (TPDF) where the noise is weighted more to 0. Then there is colored dither, where the noise is shaped (with EQs) to place the noise mainly above the frequency of listening (around 20KHz) and finally Noise Shaped (hold on: the quantisation error from trunciation is passed back into the next sample (a high pass filter). Still with me? I have been improving dBpowerAMPs random number generator, not by messing too much with pseudo random number generators (code which creates random numbers) as these are rubbish and not overly random. dBpowerAMP Reference will include random number data obtained from www.random.org these values are atmospheric collected data and are as close as you can get to pure random (hear the hiss and grey dots on a untuned television? these come from cosmic radiation, which is pretty much random).

NAudioRdWr updated, this is a base class that most dbpoweramp codecs use, it's claim to fame is to read & write audio bit depths (8, 16, 24, 32, 32 float, 64 float) with one standard call, the update included extreme efficiency work, it is now over 50% faster than SAudioRdWr (as used in dBpowerAMP R11.5). Talking of speed trialling, the other week I ran tests on the most efficient block size to read / write from hard disks, writing was pretty much the same regardless of block size, but reading - there were huge differences in speed and not what you would think, reading smaller chunks was 50% faster than reading a large chunk, odd. R12 benefits from this research.

[Spoon]

Re: dBpowerAMP Development Diary

dBpowerAMP in 2006

It is around this time of the year that resolutions are made (and broken equally quickly I might add). What does 2006 hold in store for dBpowerAMP? the long awaited Release 12 of Music Converter (full Unicode support) will appear, the opportunity has arisen to refresh dBpowerAMPs code base, these refreshes include updating to Visual Studio 2005 compiler, Microsofts latest and greatest. I know people like to bash Microsoft on Windows, but their development tools are best-of-the-best, I don't care what people say, it is the truth...and I am not talking about C#, or .net lock-in (dBpowerAMP will still be written in what I call 'raw' c++, that is without any framework except my own NClass system).

NClass? when it comes to programming, I am going to blow my own trumpet, NClass is the summation of around 7 years work a basis on which dBpowerAMP is built (back then it was called SClass), what does it do? it is a framework (as frameworks are, .NET, MFC) with specific functionality, giving almost RAD development without the tie-down of any other large chunky framework. In a nutshell a collection of 50 classes giving advanced functionality to C++ (with a slant on audio development), the foundations of dBpowerAMP. Wait for dMC R12, first time NClass is used in anger.

Back onto dBpowerAMP, R12 should yield further refinements, an on going process of quality and enhancement. A decision was made to create a more professional 'Reference' version, this will allow very advanced features to be added without the hit of causing confusion and problems in the standard (and Power Pack versions). A huge attention to detail is being applied whilst refreshing dBpowerAMPs code base, the mp3 decoder is pretty much there, wave decoder has been much improved (in functionality and ability, after all decoding a PCM wave file gives identical results), for the first time wave files will accept ID Tags (in the correct format, and not some id3 tack on the end, MusicMatch take note...). A new Codec Design (giving much more functionality to dBpowerAMP), it was around 5-6 years ago the codecs were designed, with 6 years of knowledge under my belt it is time to use that and improve on what is there, many of the old restrictions have been removed.

So what is dBpowerAMPs resolution? to deliver dBpowerAMP R12 that is the best yet.

[Spoon]

Re: dBpowerAMP Development Diary

January 2006

The first alpha version of dMC r12 is getting close...it will be about 10% of the final dMC (converting and ripping are a long way off) - currently I have popup information and explorer columns working, just finalizing configuring and x64 support and adapting the installer to install specific files on specific windows versions.

Once alpha 1 is out, alpha 2 will include an emulation layer so that older dMC R11.5 will be able to work with the newer codecs, making full use of things such as mp3 gapless (note this will not give unicode reading abilities to r11.5, as the whole program need to be be unicode not just the codec).

-----

Alpha 1 has been completed (just working on an installer to deploy the files correctly for Win64). The pop-up information & explorer columns are looking very impressive: it is possible to customize them to include any exposed information (there is alot more, Replay gain, encoder settings, Mpeg type even a new Audio Quality value that tries to rate files), or even custom tag items, for example have a tag field 'XYZ' these tags can listed in windows explorer! cutting edge stuff. Will explain more on the R12 beta page (in a few days)

-------

What an effort to get a functioning Win64 shell extension, lots and lots of hoops to jump through, but got there in the end. Alpha 1 is out the door, work can begin on Alpha 2 and more functionality.

--------

Completing work on WAVE metadata, LIST chunks are complete (effectively limited tag types, think as full ID3v1), bext and cart chunks very soon.

[Spoon]

Re: dBpowerAMP Development Diary

February 2006

Quite a tough month (writing this at the end of the month), writing back-end stuff is never rewarding, so what has completed (for R12)? well a wave encoder and mp3 (Lame) encoder are done, with various improvements - first off wave can now encode IEEE float and native mp3-wave (ie it uses lame to put mp3 into wave files).

The lame encoder is more interesting, it has moved away from lame_enc.dll and lame is fully integrated into dMCs encoder, this has the advantage of allowing finer tunings (no longer restricted to the lame_enc library), but more importantly it allows encoding using the bit depth of the source (ie 24 bit or float goes straight into lame). Freeformat encoding is now in, also using the newer -V vbr switches.

Finally CoreConverter is taking shape, this will be the unsung hero of R12, it will handle the conversions via command lines (yes the above 2 codecs accept command-lines, better for various situations), even dMC will use coreconverter. What are the advantages of this? it allows multiple small-coreconverters to be fired off at any time, crashes can be detected and contained (if converting 1000's of files it should continue if one crashes).

all in all R12 is slowly taking shape.

[Spoon]

Re: dBpowerAMP Development Diary

March 2006


No More Monologue

Previous codecs in dBpowerAMP were pretty much a one way street (the part in charge - dMC) would call specific fixed methods, not overly flexible. For R12 the river flows in both directions (a good analogy), any component (Decoder / Encoder / DSP) is able to talk privately with any other fore-mentioned component, initially only Sveta or perhaps Album based replay gain will use this, flexibility is the key.

Work is progressing nicely on the dMC user interface (select files, rename, choose audio format, convert). Every area of the existing dMC is being improved, even multi-processor capability will be built into the converter, rather than through a [multi-encoder] utility codec.


Apple Lossless Encoder

A real bonus getting that finally working, it feels good to be on the cutting edge.


Music Converter

Practically finished! the difference between R-pre12 and R12 is that Music Converter used to handle everything (ie CD Input, Aux Input, File Selector would all call music converter), now things have moved to a CLI CoreConverter (as it is called) each program can handle the operation, allows for more flexibility. Native multi CPU encoding is built into the Converter, however a bit of thought has to go into it, it is no good using multi CPU encodes if converting to a high bitrate audio file (read lossless) as the limit on encoding is likely the hard disk and adding a 2nd CPU trying to access the same hard disk is just stupid.

[Spoon]

Re: dBpowerAMP Development Diary

May 2006

This month has been dedicated to the new CD Ripper (yes a new name also), progress is going well - around 40% complete. Meta data services is almost complete, there are no less than 6 sources of meta data: AMG (a new commercial system, very accurate data with album art, etc), CD-ISRC + CD-UPC (a new refernce feature, from the subcodes of cd), CD-Text, freedb (rewritten) and CDPlayer.ini

The new CD-Ripper is fully unicode compatible and allows any meta-data per cd track (no longer fixed on one genre per cd...). Within CD Ripper its self there are many definable columns, new items such as rating and a tighter integration with AccurateRip (perhaps next month we will complete secure ripping and this AccurateRip integration).

edit: what happened to April?, answers on a postcard to...

[Spoon]

Re: dBpowerAMP Development Diary

June

4 weeks gone already? where does time go...still on CD Ripper, guess what? it actually rips something and works with accuraterip. The last week accuraterip has undergone a big update, couple of fixes and a tight integration with the host calling application (expect to see the accuraterip report in the program its self, both EAC and the new CD Ripper).

Work on secure mode is just starting (reading last moth it is 4 weeks late, oh well), we have a pretty good cache detection routine which seems to work well. Cache is important for secure rips as if you do not know the correct size (Furrio and EAC are quite poor at cache detection) then your re-rip will come from the cache not the cd which is insecure.

Thinking about it I know where the 4 weeks went, 2 went on getting CD Ripper to pipe data to the new coreconverter instead of replicating the coreconverter code in cd ripper (which at first thought would have been easy but would cause pain in the long run).

CD Ripper is about 60% done.

[Spoon]

Re: dBpowerAMP Development Diary

July 2006

Secure ripping is almost done, coding it was slightly unusual, normally computer programs are written to be precise and without error, well the first stage of developing secure ripping is not to use a scratched cd because the bad results are some what random and that does not aid debugging, it is best to artifically insert errors into rips. Once that is done and the program can correct that (under the watchfull eye of the debugger), then move onto scrached cds.

Scratched cds: for this I took 5 identical cds, one was kept in untouched perfect condition (each was ripped and compared with accuraterip, yeh for these were in the database), one was given artifical errors (a black line which gets wider to the outside of the cd) the other 3 were scratched in various ways. Then comes the tedious testing process, 1000's of rips on various drives - the real test will be when the it is released for testing.

I have to say AccurateRip, it is turning into something more than the sum of its parts (as the database gets bigger). It is really useful and is a requirement to secure ripping.