10 December 2007, 11:02 | #1 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
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 ), 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. 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... |
10 December 2007, 11:13 | #2 |
Total Chaos AGA is fun!
Join Date: Jun 2005
Location: USA
Posts: 873
|
I had wanted to optimize it myself, timeless ages ago, but I could not find the source.
Thanks for doing it for me. |
12 December 2007, 00:37 | #3 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
But seriously: muls muls muls and more muls 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 Quote:
This one will separate the men from the boys. One day I will be a man. Thanks for sharing Last edited by Thorham; 12 December 2007 at 00:47. |
||
12 December 2007, 10:07 | #4 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
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 ) . 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. No beginner's stuff, sure. It is not that an implementation in code is that hard, but I simply don't know what to do... |
||
12 December 2007, 16:15 | #5 | ||||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Quote:
Quote:
Quote:
|
||||
12 December 2007, 16:53 | #6 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
Quote:
Quote:
Quote:
Globally, I know how it works, but I need much more than a distant view to write a player... |
|||
12 December 2007, 19:19 | #7 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
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 |
13 December 2007, 10:13 | #8 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
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 |
13 December 2007, 10:24 | #9 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Quote:
|
||
13 December 2007, 11:11 | #10 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
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). If you don't find anything about mp3 then you will maybe find petroleum (if you dig deep enough ) 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). |
|
13 December 2007, 18:06 | #11 | |||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Quote:
Quote:
Trying to understand everything from just a source code really should be a last resort, unless it explains all the details. |
|||
13 December 2007, 18:07 | #12 |
Global Moderator
Join Date: Nov 2001
Location: Derby, UK
Age: 48
Posts: 9,355
|
You two guys should have your oiwn section
Meynaf & Thorams asm coding and chat - There only needs to be 2 members Only joking guys.. nice to see some asm action in here |
13 December 2007, 18:28 | #13 | |||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
Quote:
Quote:
Quote:
Which one do you prefer ? Quote:
Quote:
(and neither anything against more people to participate, too ) |
|||||
14 December 2007, 16:24 | #14 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Quote:
|
||
14 December 2007, 16:47 | #15 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
So what do you think about existing code ? Very easy to read and understand, eh ? (who said no ? )
Quote:
I fear there is some sort of copyright blocking free docs |
|
17 December 2007, 16:07 | #16 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Quote:
|
||
21 December 2007, 11:16 | #17 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
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 : Last edited by meynaf; 12 May 2011 at 08:32. |
||
22 December 2007, 23:30 | #18 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Very tough to find simple explanations for mpeg decoding 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 Quote:
|
||
24 December 2007, 10:50 | #19 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
And you can't do that on nowadays machines.
Quote:
According to libmad's layer3.c : Code:
* The Layer III formula for requantization and scaling is defined by * section 2.4.3.4.7.1 of ISO/IEC 11172-3, as follows: * * long blocks: * xr[i] = sign(is[i]) * abs(is[i])^(4/3) * * 2^((1/4) * (global_gain - 210)) * * 2^-(scalefac_multiplier * * (scalefac_l[sfb] + preflag * pretab[sfb])) * * short blocks: * xr[i] = sign(is[i]) * abs(is[i])^(4/3) * * 2^((1/4) * (global_gain - 210 - 8 * subblock_gain[w])) * * 2^-(scalefac_multiplier * scalefac_s[sfb][w]) * * where: * scalefac_multiplier = (scalefac_scale + 1) / 2 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 |
|||
24 December 2007, 15:56 | #20 | |||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
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 |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Can it be faster? | oRBIT | Coders. General | 2 | 16 May 2011 20:38 |
Chipram 3x faster? | oRBIT | Coders. General | 10 | 20 July 2010 02:13 |
mpega.library (WarpUP) problem | radzik | support.Apps | 23 | 14 December 2009 17:05 |
Making a shared library from a gcc .a library | JoJo | Coders. General | 1 | 10 March 2003 19:06 |
Faster Emu | Radgam | support.WinUAE | 3 | 27 February 2003 17:16 |
|
|