mpega.library faster than itself
Hello coders,
As you know, there is no support for mpega.library and the author can't be contacted (it seems). I asked myself if the integer version of the library, which is actually the fastest Amiga implementation of such a decoder (or I think so :p), could be optimized, and found out it could. I re-sourced it and got around 10% speed, enough to play in medium quality setting what I previously played in low. :spin Now most of the (up to) 160 kbps mp3's can be played at 22.05 medium quality and mono on a 50mhz 68030. To use it, DeliTracker's mpega player will do nicely. I don't know if it's better to rewrite it all or start from its actual code. I started both but the rewrite stopped 'coz lack of understanding of the layer3 (that is, lack of docs). You will find the actual source (reassembler output, so mostly unreadable) here : http://meynaf.free.fr/tmp/mpega.lzx (not in the zone because files don't live long enough there) Included is the library doc. Unfortunately I don't have the lvo's. More can surely be done. If someone already did something similar or is interested, you now know where to help... :help |
I had wanted to optimize it myself, timeless ages ago, but I could not find the source. :(
Thanks for doing it for me. :) |
Quote:
But seriously: muls muls muls and more muls :shocked When I saw that, I thought: Hoo boy. This thing is no joke. Must admit, I didn't read through all of the code, but thats a serious challenge you've gotten yourself into :) Optimizing this one isn't the same as the instruction juggling I've been doing for your ham rendering engine, which is small and well commented (translators are far from perfect, but they do help with the French). This is a whole different cup of tea :crazy Quote:
This one will separate the men from the boys. One day I will be a man. Thanks for sharing :great |
Quote:
Quote:
You can try to find something, too. Maybe you'll be more lucky than I was. What I did for my rewrite project is that : . reading the file (ok, not too hard :p) . parsing headers and side info (those are quite well documented) . circular buffer handling for data . reading the scale factors But now the next step is to read huffman data. That is, do the work that III_huffdecode() in libmad's layer3.c does (note that I concentrate on layer3, else I wouldn't have any file to test). It's not just reading huffman codes, something is done on the fly with the data. Quote:
|
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
Globally, I know how it works, but I need much more than a distant view to write a player... |
Searching for docs and sources didn't yield a whole lot of results, but I think the following links will be interesting.
MP3' Tech - MPEG source codes Has multiple mp3 decoder sources, amongst other things. MP3 - Hydrogenaudio Knowledgebase Looks like a nice page with some potentially interesting links, including one that describes huffman decoding. www.eecs.umich.edu/~accheng/doc/MP3Decoder_AllenCheng.pdf Seems to be an in-depth description of mp3 decoding. www.mp3-tech.org/programmer/docs/fpga_report.pdf Also a more in-depth description. It's a hardware implementation, but that shouldn't matter too much. These are the best I could find without searching for hours, and although I'm sure they'll make for some interesting reading, I hope some of it is actually of some use to you. If not, I'm going to have to dig a 'little' deeper :D |
These are interesting reading indeed, but yet not precise enough to actually write a decoder. Existing code is the best doc I have found so far : I have the sources for mpeg3play, mpg123, and mad. They're not too commented...
Maybe you'll have to dig a little deeper :D |
Quote:
Quote:
|
Quote:
The more interesting are mpg123, because it's the most readable I've found (but very very slow as it uses floating-point), and libmad (which is much faster as it uses fixed-point, that is, integer). Quote:
What I need right now is either an optimization for mpega, or a detailed algorithm to decode layer3's particular huffman codes (just knowing how huffman works is not enough). |
Quote:
Quote:
Quote:
Trying to understand everything from just a source code really should be a last resort, unless it explains all the details. |
You two guys should have your oiwn section ;)
Meynaf & Thorams asm coding and chat - There only needs to be 2 members :laughing Only joking guys.. nice to see some asm action in here :D |
Quote:
Quote:
Quote:
Which one do you prefer ? Quote:
Quote:
(and neither anything against more people to participate, too :agree) |
Quote:
Quote:
|
Quote:
Quote:
I fear there is some sort of copyright blocking free docs :( |
Quote:
Quote:
|
Quote:
Quote:
If you can't find something in here, then I have something else that could be useful to accelerate : my 44.1 khz 14-bit rendering code. Here : |
Quote:
Very tough to find simple explanations for mpeg decoding :scream However, I was able to work out that the huffman code seems to differ from normal huffman code in that it outputs variable length data (has to do with the scaling factors if I'm not mistaken) instead of fixed length data. This has lead me to believe that the only thing that happens during the huffman decoding stage is scaling the data to some fixed length. If this is correct, then it should not be to hard to extract this from one of the source codes you have, and make your own routine based on this. After searching the web for a while, it began to dawn to me that you have two choices: 1. Go through trouble of learning how layer 3 really works, including the math. 2. Go through the trouble of understanding someone else's source code. Personally I'm not a math guy, as you know, so I would definitely go for option two. Of course, you probably came to the same conclusion :D Quote:
|
Quote:
Quote:
According to libmad's layer3.c : Code:
* The Layer III formula for requantization and scaling is defined by Quote:
Quote:
Remember that we can't play that 16-bit 44.1 data directly ; we have to downsample it before, and prepare it for 14-bit output. My code does this in 5:3 instead of the usual 2:1, leading to 26460hz instead of 22050 (better quality). But, of course, this takes some time. When I use mpega I'm often at 95% cpu use (when there aren't gaps in the replay !), so it's worth removing whatever we can. This code must write to chip memory, and there are nasty divides in it. You sure know these things aren't fast ;) |
Quote:
Quote:
Quote:
It's a big shame the audio dma can only be doubled by doubling the screen scan rate, otherwise the down-sampling wouldn't be needed and one could just chop off two bits, would be faster and sound better. By the way, have you ever thought of a 15bit routine by any chance? I know I should probably not be bringing this up (will slow things down), but I just couldn't resist :D |
All times are GMT +2. The time now is 01:07. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.