Yes I have pets. I have some fishes in an aquarium. They are easy to take care of and are nice to look at. They don’t shed, make noise or demand much of my time. IMO the perfect pet. But can they get even more perfect? I bought an automatic feeding machine for them, so now I can forget about them for weeks without them starving to death.
I just have to update the status on this, the transform IS perfectly revertible.
http://research.microsoft.com/~malvar/papers/dfsp98.pdf describes it as this:
“They lead to perfect reconstruction as long as the butterflies in the inverse transform are the inverses of those in the direct transform.”
Which the transform in atrac fullfills. The Multimedia Wiki has the exact details of the window generation. The equation on page 2 in the Malvar paper matches the window generation code.
Atrac as almost every codec uses Huffman coding to compress the spectral coefficients. Huffman code can only be done in one way but various optimizations can be done to the actual symbol recovery process. In Atrac they implemented a fast scheme working like this:
This might not be so easy to understand so lets take an example.
hufftable[8] = {{0, 1}, {0, 1}, {0, 1}, {0, 1}, {1, 3}, {2, 3}, {3, 3}, {4, 3}};
{0, 1} the first value is the actual symbol and the second is the amount of bits in the code. In this table the maximum amount of bits to read is 3 and we have 5 symbols. So when we lookup a value we always read 3 bits. For example we get the value 011 in binary 3 in decinal, when we look at index value 3 we get {0,1} so the symbol is 0 and the actual code only has 1 bit and the code is the binary 0. If we get the binary 101, decimal 5 we get {2, 3}, so the symbol is 2 and the amount of bits in the code are 3. If we check all possible values we get this table:
0 -> 0 100 -> 1 101 -> 2 110 -> 3 111 -> 4
And if we map the table to a tree we get this not so beautiful result:
/\ 0 /\ /\ /\ 1 2 3 4
In this tree left is 0 and right i 1.
ATRAC uses 2 transforms to achieve it’s compression. First a QMF (Quadature Mirror Filter) filterbank splits the signal into 3 bands and then each of the bands are transformed with a MLT (Modulated Lapped Transform). What I’ve been looking at now is the MLT transform. What is a bit strange with this one is that the MLT window used isn’t fullfilling the Princen-Bradley condition. Which means it doesn’t produce perfect reconstruction of the data. That doesn’t have to be bad or anything it’s just the first time I’ve seen it in actual use. Other codecs using MLT (wma,vorbis,aac) use a reversible transform. Ie the stuff you put in and transform is the same stuff you get back if you do the reverse transform. This is true if you don’t through away stuff in the transformed state, which all of them do. But if you always through away data after you do the transform you don’t actually need a perfectly revertible transform. So my guess is that the Sony folks tried to find some middle ground with a transform that wasn’t perfectly revertible.
As an update to the AMV post, Reynaldo H. Verdejo Pinochet has written a MTV demuxer. The demuxer is implemented as a lavf demuxer. So expect support for the format in your favourite media player in a few weeks. The format is basicly mp3 audio and raw RGB video interleaved in one file. A sample file can be downloaded here.
The article on Wikipedia classify ATRAC in 4 diffrent modes: ATRAC1, ATRAC3 LP2, ATRAC3 LP4 and ATRAC3plus. I classify it a bit diffrent. In an “interesting target order”, first we have ATRAC3 and then ATRAC3plus, ATRAC1 is not of interest at all because it’s not used in a computer friendly environment (ie no sample files available). The order is based on the use of the codes. ATRAC3 (LP2 and LP4 is considered as one codec) can be found in 3 (or 4 depending if you define wav as a container and 5 if you consider a few PSP files with ATRAC3 in mpeg ps files) different containers. The well known avi container, the less known (but popular) rm container and the almost unknown oma container. Sony released a windows acm codec that could be used to put ATRAC3 into wav and thus also avi. RealNetworks used ATRAC3 for their RealPlayer8 release and that’s how it came into the rm container. And finally it is used in oma with the Sony SonicStage music manageing/store software. ATRAC3plus is currently only known to exist in oma files. So now we have the possible containers and what software uses what codec. From this we now search for a good target vector. Ie how do we go forward from this and where to start. What is needed are sample files, an easy to understand binary and preferably an easy way to test reimplemented code. When I evaluated all the options I found that RealPlayer had several debug binarys for linux and an easy way of runnig the code (through mplayer with realplayer support). Thus the path would start at the rm ATRAC3 files and then go on with wav/avi. After that figure out the oma container and how ATRAC3 is stored in it. When all that is done we continue towards the ATRAC3plus format backed with all the information from the ATRAC3 codec and the oma container. We’ll see how much of this is going to be done but it’s a decent roadmap to start with.
In my morning newspaper I found an ad for a mp3player, the price vs featureset was quite compelling so I researched it some more. The Inovix IMP-5500 IPocket had one feature that caught my eye. Video format: AMV. What on earth is AMV? Well I don’t have the answer but Wikipedia has some info and links about it. I located an encoder for the AMV format so now there are no excuses to not take it apart and see what it actually is and how to decode it. The information from Wikipedia suggest that it atleast uses mp3 for the audio but the video format is still unknown.
In the beginning of the digital music revolution one company had quite a big market. It was Sony with it’s Minidisc players. You weren’t actually able to access the digital audio files on the discs but there where perceptually coded digital audio files there. The codec used had the name ATRAC (short for Adaptive TRansform Acoustic Coding). Eventually they migrated to flashbased players to compete with the popular mp3 players but unfortunately or not they didn’t get any significant marketshare. So their proprietary technology almost went the way that other closed formats went (vqf, etc), away. But Sony being a big company with lots of money and that they kept trying to push their format onto the consumers. So this format that should have been long forgotten is still in active use. The Sony PSP uses it and lots of their new players support it, even though some of them now supports native mp3 files. They even recently released some software that lets you create those files. www.atraclife.com link. So what’s it with this format that is so good that they won’t let it die. That’s what I’m gonna try to find out in the following posts. For the time being some of the technical details can be found in Wikipedia.