mad-dev

mad-dev@lists.mars.org

682 discussions

unsusbcribe
by Alain 02 Apr '04

02 Apr '04

unsusbcribe ___________________________________________________________ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes

1 0

Starting/stopping decoding of same stream
by Erik Jälevik 30 Mar '04

30 Mar '04

Thanks to Rob and Tony for the answers to the channel question. I'm trying to implement a class within my C++ app that presents a stream interface to the MAD decoder, i.e. it does buffering and provides a Tick() method that returns the next decoded sample in the stream as a floating point number. My first attempt uses the high-level API but I've stumbled on a problem I can't seem to get around. The logic I'm using in Tick is something like the following: 1. Check PCM buffer. 2. If data present, just return next sample. 3. If buffer empty, go away and decode some more to fill buffer. 4. When buffer is full, stop decoding and return first sample in buffer. I need to stop and start decoding the same stream at regular intervals depending on the PCM buffer size. So at stage 3 above, I call mad_decoder_run on the properly initialised decoder, and in the output callback, I return MAD_FLOW_STOP when I've been given enough frames to fill the buffer. Up until now everything's fine. But, it seems that the next time the buffer gets empty and I restart by calling mad_decoder_run again on the same decoder, the decoder doesn't remember the input last given to it by the input callback. So the first thing it does is call the input callback for more input. The mad_stream->next_frame passed into the input callback is always 0 after a restart. This causes problems because the input callback has no way of knowing how far into the previous chunk MAD has decoded. Is there any way to find this out from the decoder itself? I haven't looked at the low-level API yet, will I maybe need to use that to achieve what I want? Hope the above makes sense, I've only just started using MAD so might have overlooked something blindingly obvious. Many thanks, Erik

4 8

RE: Re[4]: [mad-dev] III_requantize() accuracy
by Tony Francis 27 Mar '04

27 Mar '04

Hello Gregory, In the link that you had provided, they are talking about the output pcm bit width and not about the fixed point data width. And some use floating point Math. But I couldn't understand the logic why you have to stick to 4.28x1.31 alone. One thing I always thought was why it was necesssary that you should stick to 4.28 * 4.28 giving 4.28 itself. I can have some thing like 4.28 * 2.30 giving 5.27. After all your maximum pcm bit width at output is 24 and 27 fractional bits will give you the same effect as 28 fractional bits. I had worked on a 3DSP processor some 3 years before but I don't remember any thing about it. How is the multiplier in 3DSP? I remember it as a 32 bit processor and I think there was a multiplication instruction which gives you the upper most 32 bit result of a 32 by 32 multiplication and is this the reson why you wants 4.28 by 1.31 multiplication? One more thing accuracy test is to be done only for compl.bit in ISO test streams I believe. Have a nice week end. Cheers, Tony -----Original Message----- From: Grigory A. [mailto:Ryhor@tut.by] Sent: Friday, March 26, 2004 1:49 PM To: Tony Francis Cc: mad-dev(a)lists.mars.org Subject: Re[4]: [mad-dev] III_requantize() accuracy Hello Tony, Friday, March 26, 2004, 2:53:52 PM, you wrote: TF> With 16 bit implementation on TI55x how much accuracy you got? And TF> how much accuracy improvement was there by changing the TF> multiplication into 4.28 by 1.31 instead of 4.28 by 4.28 used in MAD TF> decoder? According to http://www.underbit.com/resources/mpeg/audio/compliance/ in best case limited accuracy is achieved. But in worst case ... rms still C*10^-4 but C - is bigger than limited accuracy require. 4.28x1.31 - I just have to use this one :) This is 3DSP hardware dependent - in another case - like 4.28x4.28 I need to do additional actions... So almost in all places decoder use constants less than 1.0 Only in synthesis part some of them are bigger than 1. But now I am working under synthesis and I am looking in way where constant which are bigger than 1 will be split on 2 part. After I finish decoder we can measure accuracy :). -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

RE: Re[2]: [mad-dev] III_requantize() accuracy
by Tony Francis 26 Mar '04

26 Mar '04

Hello Gregory, With 16 bit implementation on TI55x how much accuracy you got? And how much accuracy improvement was there by changing the multiplication into 4.28 by 1.31 instead of 4.28 by 4.28 used in MAD decoder? I am not very sure whether a floating point version of MAD is there, but if not what about creating one? Some RISC processors have fpu now and it may be of interest for some. Cheers, Tony -----Original Message----- From: mad-dev-admin(a)lists.mars.org [mailto:mad-dev-admin@lists.mars.org] On Behalf Of Grigory A. Sent: Thursday, March 25, 2004 7:06 AM To: Rob Leslie Cc: mad-dev(a)lists.mars.org Subject: Re[2]: [mad-dev] III_requantize() accuracy Hello Rob, Wednesday, March 24, 2004, 7:12:59 PM, you wrote: RL> Keeping in mind that 2^(-36.75) = 2^(-36) ? 2^(-3/4), you will find RL> that III_requantize(210, -147) calculates: RL> 210^(4/3) ? 0x04e0393e ? 2^12 RL> 0x04e0393e ? 2^(-36+12) ? 0x00000005 RL> 2^(-3/4) ? 0x09837f05 RL> 0x00000005 ? 0x09837f05 ? 0x00000002 RL> I think the difference is due to rounding errors from the limited RL> precision of the fixed-point type. You're talking about a difference of RL> 3.725e-9, pretty insignificant in the grand scheme of things. RL> If you configure with --enable-accuracy, you'll get a slightly RL> better fixed-point multiplication in the last step that happens to RL> yield the value you were expecting. Yes I am agree. Only one difference in my calculation scheme I firs multiply on root - in this case 2^(-3/4) and next rounding and shifting. This small changes give more precise result. And why I am talking about it. Now I am "porting" MAD 0.15 to 3DSP platform www.3dsp.com this is 32 bits dsp with 32x32 multiplier - so I am expect good result. Now at my decoder differences after III_requantize() are +-1 only - but at synthesis time sbsamples have +-25 with average rms ~1.2e-8 compare to MAD. My calculation is performed in 4.28x1.31 format - so error coming from this last bit in 4.28 representation of Xr data. And - I have working "MAD" decoder for TI tms320vc55xx series dsp - but it is 16 bits implementation - so only limited accuracy and some time even worst :). If some one need - I can send it. Later I will publish it on web. -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

RE: [mad-dev] No of channels constant?
by Tony Francis 26 Mar '04

26 Mar '04

Hello Erik, That is the case with normal files but ISO test stream has one file (l3-he_mode.mpg) which starts with mono then switches to dual and then joint stereo. (For testing only I believe) Regards, Tony -----Original Message----- From: mad-dev-admin(a)lists.mars.org [mailto:mad-dev-admin@lists.mars.org] On Behalf Of Erik Jälevik Sent: Thursday, March 25, 2004 6:51 PM To: mad-dev(a)lists.mars.org Subject: [mad-dev] No of channels constant? Sorry if this is slightly off topic but I don't know of any other place where people might know the answer. Is the number of channels an MP3 file is encoded in always constant? Or can it change from stereo to mono somewhere in the middle? Or to phrase it differently: Can I always assume that pcm->channels has the same value within the output callback as long as I'm working on the same file? Thanks, Erik

1 0

short imdct
by Rafael Ávila de Espíndola 26 Mar '04

26 Mar '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any reason for not using the Szu-Wei Lee's algorithm for the short IMDCT (size 12)? Annexed is a patch witch implements it. Rafael Ávila de Espíndola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQO/RLlrfGJ8JUHwRAogGAJ9c8dZFc+vHM5SJ94FJGgJ8g2IJWQCfbyr5 qczH/qDxC7XBLkbkXn6mGcQ= =gjVQ -----END PGP SIGNATURE-----

2 1

No of channels constant?
by Erik Jälevik 25 Mar '04

25 Mar '04

Sorry if this is slightly off topic but I don't know of any other place where people might know the answer. Is the number of channels an MP3 file is encoded in always constant? Or can it change from stereo to mono somewhere in the middle? Or to phrase it differently: Can I always assume that pcm->channels has the same value within the output callback as long as I'm working on the same file? Thanks, Erik

2 1

III_requantize() accuracy
by Grigory A. 25 Mar '04

25 Mar '04

Hi! I am again about accuracy. input parameters exp=0xffffff6d=-147 -> -(36.75) right? value d2=210 >> 210^(4/3)*2^(-36.75)*2^28 ans = 2.89921171527700 my answer 3 MAD 0.15 - #define FPM_INTEL answer 2 What is the problem? Thanks for answer. -- Best regards, Grigory mailto:Ryhor@tut.by

2 3

USound: new sound daemon that includes madplay patches
by Matt Campbell 24 Mar '04

24 Mar '04

Hello, I'm working on a new sound daemon for Unix called USound (the Useful Sound Daemon). It's somewhat like esd but aims to be more useful, particularly by having lower latency and better sample rate conversion. One of the first applications I needed to use with USound was madplay, so I added USound support to madplay and included the new source file and diffs in the USound source distribution. You can download USound from: http://pobox.com/~mattcampbell/usound/ The new source file and diffs for madplay are in the usound/clients/madplay directory. I hope these changes will be integrated into the official madplay distribution. Please let me know if you find any problems with my changes or USound in general. Thanks, Matt Campbell

2 1

#define CHAR_BIT 16
by Grigory A. 14 Mar '04

14 Mar '04

H! In my system minimum accessible variable is 16 bits wide. So I can use two technique I. Use low part of my 16 bits wide char. Use default #define CHAR_BIT 8 - this one working well. II. Try to use #define CHAR_BIT 16. This one has several problems 1. in decode_header() here sync: ... else if (!(ptr[0] == 0xff && (ptr[1] & 0xe0) == 0xe0)) { ... goto fail; } I solve it by else if (!((ptr[0] & 0xffe0) == 0xffe0)) it works. 2. III_huffdecode() function. I guess problem is here: // ---- align bit reads to byte boundaries ----- takes up to 32 bit ?? cachesz = mad_bit_bitsleft(&peek); cachesz += ((32 - 1 - 24) + (24 - cachesz)) & ~7; ... or here: if (cachesz < 21) { unsigned int bits; bits = ((32 - 1 - 21) + (21 - cachesz)) & ~7; ... It isn't work - at the middle of mp3 file I have MAD_ERROR_BADHUFFDATA So could you say to me these numbers: 32, 24, ... - what is the reason and how to calculate them for my case #define CHAR_BIT 16 ? And what I need to do more - to work with 16 bits wide char? Thanks for answers. -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

← Newer
1
...
26
27
28
29
30
31
32
...
69
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev