mad-dev July 2002

mad-dev@lists.mars.org

12 participants
12 discussions

skipping frames
by ajoshi＠kernel.crashing.org 30 Jul '02

30 Jul '02

Hi, I was wondering if there was anything in the current libmad API for frame skipping? For example, skipping ahead 1,2, or 4 frames and same for rewind. I understand I can do this directly on my stream but then what would be a clean way to update the mad_stream, and does it need updating? Or can I just call mad_stream_buffer() and it'll figure things out itself? I checked the list archives but couldn't find exactly what I needed, sorry if this question is redudant, as I'm sure it is. Thanks, ani

2 1

multithreading
by Faust A. Tanasescu 25 Jul '02

25 Jul '02

Hello I am in the process of completeing my application. Here's what it does. The main tangible interface is a joystick. The main thread called the engine sits in the background and creates new threads as needed when the user wants it to. For example, when one hits button 1 of the joystick, mp3 decoding starts. When Joystick is moved to the left, it skips to the next song and so on. That's where mad comes in. The engine is completed and operational. Now I need to hack mad to suit my needs. What I need from mad is - ability to build a playlist from sources listed in a configuration file (that's the easy part) - stop/play mp3 decoding as needed: That is the main thread called engine controls mp3 playback via a flag maybe (inter-thread communication). I have taken a look at the code, yet I am a bit unsure how the second paragraph can be done with mad easily... That is to say I want something very high-level and powerful as well. I would've taken a look at the API doc, but ... I don't know what to do to acheive my goals... Anyways suggestions/comments welcome. davoid

3 2

Stream Syncronization..
by Reza Naima 24 Jul '02

24 Jul '02

I managed to find this thread in the archives wich helped quite a bit : http://www.mars.org/mailman/public/mad-dev/2002-January/000426.html And this is a great simple description of the MP3 header : http://www.id3.org/mp3frame.html I followed the advice posted, and wrote a simple routine to find the start of the next frame (some lines removed for clarity) : int rio_mad_findNextFrame(char *data, unsigned int dataSize) { [init stream, frame, initalize other variables] for (i=0; i<dataSize-1; i++) { if ( data[i] == 0xff && (data[i+1] & 0xe0) == 0xe0 ) { mad_stream_buffer(&stream, data+i, dataSize-i); if ( mad_header_decode( (struct mad_header*) &frame.header, &stream) != -1) { frameOffset = i; break; } } } [cleanup stream, frame] return frameOffset; } Which seems to work great, as it the frame.header object has all correct values in it. However, when I take this offset into account and then call mad_stream_buffer() (different stream struct) in the main loop of the program, I promptly get a "bad main_data_begin pointer" error from MAD. What should the first byte passed to mad_stream_buffer() be? Shouldn't the first byte be the Sync byte (value of 0xff)? Again, The full code can be found here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/grrr/rrr/mad.c and the other relevant function is rio_mad_shoutcast_input(). Thanks, Reza

2 2

Shoutcast & MAD
by Reza Naima 23 Jul '02

23 Jul '02

I'm trying to implement shoutcast decoding using MAD and I'm hitting a problem right off the bat. The first chunk of data I feed to mad_stream_buffer() results in a varying assortment of errors (returned to me via the error callback). I've used mpg321's read_from_fd() as an example, and it doesn't seem like there is any processing of the data done before the data is sent to mad_stream_buffer(). I know there are meta-data blocks in the stream, but I get these errors before I encounter the first meta-data block. The code can be found here : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/grrr/rrr/mad.c?rev=1.1.1.1&c… and the relevant function is rio_mad_shoutcast_input(). Any suggesetions would be appreciated. Thanks, Reza p.s. I've noticed this text in a lot of headers returned from shoutcast servers : icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> but I'm guessing those notices can be ignored, right? They're not doing anything special with winamp?

1 0

Re: mad-dev digest, Vol 1 #188 - 1 msg
by Kshitiz Malik 22 Jul '02

22 Jul '02

Hi! Thanks a ton Rob, for the help. However....... If the first 9 bits(in MPEG 1 Layer 3) of sideinfo referred to main_data_begin, as you pointed out, then I'm absolutely clear about the way main_data is collected(i.e, if the first 9 bits are main_data_begin, which is a negative offset from the beginning of the frame which points to the start of the current frame's main_data). However, ISO/IEC 11172-3 does refer to the first 9 bits as "main_data_end" (please see section 2.4.1.7 of 11172-3, and figure 3-A.7.2 of the same document). The above mentioned figure also illutrates that main_data_end(or the first 9 bits) is a negative offset from the end of the frame pointing to the 'end' of the current frame's main_data. Now, I understand that these 9 bits are probably actually a negative offset from the beginning of the frame(all the mp3 files I've seen have these 9 bits = 0 for the first frame, which points to the fact that this is probably a negative offset from the beginning), but the standard clearly states otherwise(i.e, it states that this is a negative offset from the end of the frame, pointing to the end of the current frame's main_data). Did I read the standard wrong, or did I read an older version of the standard, or did ISO publish errata for 11172-3, or is it an error in the standard, or, the least likely of the above, is this a bug............ By the way, I have been working on developing a parallel version of MAD, and uptil now, I have written two programs which run on a Beowulf Cluster which use MAD's code and decode mp3 files in parallel(there was a requirement to analyse strategies for decoding audio in parallel). Both of these perform decently well, with a linear scaleability :-). If Rob(or anyone else) is interested in these, do tell me. I also have lots of profiling data on mp3 decoding using MAD, which clearly show the most computationally intensive functions. And Rob, thanks for writing MAD! If there's any way in which I can contribute to further development of MAD, I'll be honored. Kshitiz --- mad-dev-request(a)lists.mars.org wrote: > Send mad-dev mailing list submissions to > mad-dev(a)lists.mars.org > > To subscribe or unsubscribe via the World Wide Web, > visit > http://www.mars.org/bin/mailman/listinfo/mad-dev > or, via email, send a message with subject or body > 'help' to > mad-dev-request(a)lists.mars.org > > You can reach the person managing the list at > mad-dev-admin(a)lists.mars.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of mad-dev digest..." > > > Today's Topics: > > 1. Re: MAIN_DATA buffer (Rob Leslie) > > --__--__-- > > Message: 1 > Date: Fri, 12 Jul 2002 09:32:54 -0700 > Subject: Re: [mad-dev] MAIN_DATA buffer > From: Rob Leslie <rob(a)mars.org> > To: mad-dev(a)lists.mars.org > > On Friday, July 12, 2002, at 01:09 AM, Kshitiz > Malik wrote: > > I have been struggling with MAD's code for quite > some time now, and have > > managed to understand almost all of it - except I > haven't been able to > > figure out the way it manages a buffer of > main_data for mp3 files. (I am > > working solely on the MP3 part of the decoder) The > problem is, the > > function mad_frame_decode(which decodes ONE entire > frame, excluding the > > polyphase filterbank) works as follows: > > > > 1) Read the sideinfo(the header's already been > decoded) > > > > [ I don't know why, but apparently Rob had > named all main_data_end > > pointers > > as main_data_begin. Of course, main_data_end > for one frame is the > > beginning > > of main data for the other frame.... but > they're slightly misleading > > ] > > main_data_begin is the name used by ISO/IEC 11172-3 > to describe the offset > of the beginning of a frame's main_data relative to > the frame's header. It > also happens to be the end of the previous frame's > main_data, but in the > context of decoding the current frame, > "main_data_begin" should not at all > be misleading. > > Note that although it is a positive number, it > denotes the number of bytes > *before* the current frame that the main_data > actually begins, not > counting bytes used by previous frame headers or > side information. > > > 2) Depending on the value of main_data_end of the > current frame, > > it collects together the main_data which has > been buffered till now in > > an array, stream->(*main_data). I couldn't > figure out how Rob does > > this. > > He actually looks at the NEXT frame, reads its > main_data_end pointer, > > calculates > > a variable named frame_space according to: > > frame_space = stream->next_frame - > mad_bit_nextbyte(&stream->ptr); > > This is the no. of bytes of main_data(which may > belong to ANY of the > > subsequent frames) > > present in the current frame. > > So far, so good. > > Next up is the statement: > > md_len = si.main_data_begin + frame_space - > next_md_begin; > > > > This has me absolutely stumped. > > This calculates the effective length of the current > frame's main_data: the > number of bytes between the current frame's > main_data_begin and the next > frame's main_data_begin. frame_space is the number > of bytes between the > end of the current frame's side info and the next > frame header, i.e. as > you said, bytes of main_data which may belong to > *any* of the current or > subsequent frames. We add to this the number of > bytes of main_data > preceding the current frame (i.e. main_data_begin) > and then subtract the > number of bytes belonging to the next or subsequent > frames (i.e. > next_md_begin). > > To make things clearer, imagine the case when > main_data_begin is always 0. > In this case, every frame's main_data is contained > entirely between frame > headers, and the length is exactly frame_space. Now > consider one frame > whose main_data_begin is 1, but the rest are still > 0. The main_data length > of this frame is one byte larger because it begins > one byte earlier. The > main_data length of the *previous* frame is one byte > smaller. > > > From this point onward, I absolutely cannot > understand the way Rob is > > bufferring > > up main_data. I see a couple of memcpy's(), and > I can guess what's > > happenning, > > but I'm not really sure. > > Also Rob, how did you manage keeping a > main_data buffer without using > > a circular > > queue?? > > The general assumption is that once a frame has been > decoded, its frame > data area will no longer be accessible, so any data > that might belong to > future frames is copied to the main_data buffer. > When the next frame is > processed, the rest of the frame's main_data is > appended to the buffer in > a contiguous fashion and the audio data is decoded. > Then the buffer is > re-initialized with the remaining data that might > belong to future frames, > and the process repeats. > > > 3) After all this is done , III_decode is called, > which is passed a > > pointer named ptr, > > which happens to point to the beginning of > main_data for the current > > frame. > > III_decode actually decodes the Huffman bits > ....and does the actual > > decoding. > > > > Can somebody please help me out with how the > main_data buffer is built up > > (I know the basics, i.e, main_data of the current > frame may be present in > > any of the previous frames, mani_data_end is a > negative offset from the > > end of the frame...etc...etc) > > I think this might be the source of your > misunderstanding: there is > nothing called main_data_end, and main_data_begin is > a negative offset > from the *beginning* of the frame, not the end. > > Cheers, > > -- > Rob Leslie > rob(a)mars.org > > > > > End of mad-dev Digest __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

1 0

vorbis spec released
by Joshua Haberman 19 Jul '02

19 Jul '02

Rob, Now that vorbis 1.0 has been released and accompanied with what looks like a complete specification (http://www.xiph.org/ogg/vorbis/docs.html), do you plan to write an integer vorbis implementation? Josh

2 1

madplay for ucb1200 device
by Sang Hoon Lee 18 Jul '02

18 Jul '02

Dear experts, I installed madplay on StrongArm board using ucb1200 device. I think that the pcm or wav output file is correct, but when I run the madplay for playing mp3 file, the result is somewhat weird. I mean, if I play 30 sec's mp3 file with madplay, the output sound's length is about 28 seconds. So, the voice's frequency in that mp3 file sounds somewhat higher than that of the original. Please give me the light what I'm doing wrong. The followings are my experimental circumstances. compiler : arm-linux-gcc (skiff tool chain) changes : 1) compile with -DFPM_ARM option instead of FPM_INTEL 2) change audio device name in audio_oss.c /dev/dsp(audio?) -> /dev/ucb1200 source file : 44100kHz, stereo,(also tried mono file), 128 kbps, mp3 (When I hear the output pcm sound with other tool, it sounds good. but just only when using madplay for play mode, it sounds some higher (in frequency) and its play time is shorter.) Thanks for reading, and any comment will be welcomed. Best Regards, bawui

2 1

MAIN_DATA buffer
by Kshitiz Malik 12 Jul '02

12 Jul '02

Hi! I have been struggling with MAD's code for quite some time now, and have managed to understand almost all of it - except I haven't been able to figure out the way it manages a buffer of main_data for mp3 files. (I am working solely on the MP3 part of the decoder) The problem is, the function mad_frame_decode(which decodes ONE entire frame, excluding the polyphase filterbank) works as follows: 1) Read the sideinfo(the header's already been decoded) [ I don't know why, but apparently Rob had named all main_data_end pointers as main_data_begin. Of course, main_data_end for one frame is the beginning of main data for the other frame.... but they're slightly misleading ] 2) Depending on the value of main_data_end of the current frame, it collects together the main_data which has been buffered till now in an array, stream->(*main_data). I couldn't figure out how Rob does this. He actually looks at the NEXT frame, reads its main_data_end pointer, calculates a variable named frame_space according to: frame_space = stream->next_frame - mad_bit_nextbyte(&stream->ptr); This is the no. of bytes of main_data(which may belong to ANY of the subsequent frames) present in the current frame. So far, so good. Next up is the statement: md_len = si.main_data_begin + frame_space - next_md_begin; This has me absolutely stumped. ____________________________________________________________________________ ||| header +sideinfo | main_data ||| head + si | main_data ||| ----------------------------------------------------------------------------- ^ ^ si.main_data_begin next_md_begin If frame_space was the length of main data in the second frame above, md_len would be "the no. of main_data bytes in the next frame". But frame_space is the length of the first frame (above), so I don't really know what md_len stands for. Can someone please help me out here??? From this point onward, I absolutely cannot understand the way Rob is bufferring up main_data. I see a couple of memcpy's(), and I can guess what's happenning, but I'm not really sure. Also Rob, how did you manage keeping a main_data buffer without using a circular queue?? 3) After all this is done , III_decode is called, which is passed a pointer named ptr, which happens to point to the beginning of main_data for the current frame. III_decode actually decodes the Huffman bits ....and does the actual decoding. Can somebody please help me out with how the main_data buffer is built up (I know the basics, i.e, main_data of the current frame may be present in any of the previous frames, mani_data_end is a negative offset from the end of the frame...etc...etc) Thanks a lot!! Kshitiz __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

2 1

RVA2 Support
by Ross McKillop 03 Jul '02

03 Jul '02

What is the status of the talked about RVA2 support - I'd heard from others that madplay either DID support it or was going to - is this included yet? Ross

2 1

Re: [mad-dev] The BIG picture
by Umar Qureshey 03 Jul '02

03 Jul '02

Hi Rob, My board uses the Cirrus CS4340 DAC. I guess what I'd like to know is would I need to come up with a driver which will take the data from a system file (such as /dev/dsp) and feed it to the DAC or is there some sort of generic implementation out there which I can tweak? Is OSS such a generic implementation? Thanks, Umar On Monday, July 1, 2002, at 03:46 PM, Umar Qureshey wrote: > I am working on a custom EP7212-based board running on Linux 2.4.18. I > would like to know what the "big picture" is of running mp3s on my > ARM-based board. From what I have gathered, I'd need to output mad's raw > PCS streams to a device in the /dev directory which would be linked to > the DAC. Is this correct? How would I create this link? Getting application PCM samples to your DAC is the business of the operating system's audio driver; the details depend on which driver you plan to use. If you use OSS, the interface is usually through /dev/dsp or /dev/sound/dsp. Actually the name is unimportant; what matters are the device major/minor numbers. Under Linux, /dev/dsp should be a character device with major number 14 and minor number 3; it can be created with `mknod' if it doesn't already exist. The device numbers link the node to the audio driver in the kernel, which then passes your PCM samples to your sound hardware. > Also, is there any special hardware initialization that needs to be done > to preset the board for decoding? If someone can outline the general > sequence before I delve into the details, that'll be very useful. Thank > you! I'm not familiar with the EP7212 in particular, so I'm not sure I can answer this question. However, if the board is running Linux, I imagine most of the details are handled for you by the OS. -- Rob Leslie rob(a)mars.org

1 0

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 July 2002