Rockbox mail archiveSubject: libwma generates lower output volume than libavcodec
libwma generates lower output volume than libavcodec
From: James Hag <james_recmp_at_yahoo.co.uk>
Date: Wed, 6 Apr 2011 16:06:20 +0100 (BST)
Decoding WMA streams (e.g. Codec: wmav2, Bitrate: 128kbps, Sample rate: 44.1KHz, Channels: 2) with libwma on mplayer causes the output volume to be lower than with libavcodec, but libavcodec has a high cpu usage on the ARM processor I'm using (it has no hardware support for floating-point arithmetic).
The issue with libwma appears to be down to the multiplier (mult) used when computing the MDCT coefficients in function 'wma_decode_block' in libwma/wmadeci.c. The multiplier always gets rounded off to 0. Whereas, in function 'wma_decode_block' in libavcodec/wmadec.c, the multiplier is a 'float' and has a non-zero value assigned to it.
One way to fix this is to increase the offset for the total_gain value to be used in the 'pow' lookup table by 12.
diff --git a/libwma/wmadeci.c b/libwma/wmadeci.c
- fixed32 mult3 = (fixed32)(fixdiv64(pow_table[total_gain+20],
This causes the decoded wma streams to end up with the same volume as that of libavcodec.
Are there any potential problems with making this change? For example, would if be possible for a lookup in the pow_table to be out of bounds if the offset is increased?
There are three instances of the +20 offset used when looking up values in the pow_table in function 'wma_decode_block'. Would the offset need changing for all these instances?
Page was last modified "Jan 10 2012" The Rockbox Crew