mad-dev

mad-dev@lists.mars.org

682 discussions

about the compliance test result on libmad ( ver 0.14.2b) -2
by pltsai＠globalunichip.com 15 Oct '02

15 Oct '02

<he_mode.hex>:261504 samples line 11701: f1e918 000129 f182e7 000156 f11ebb 000189 f0bf59 0001c0 <he_mode_intel.hex> : 147456 samples line 11701: 123809 1269A2 129421 12B5B7 12CEBB 12E192 12F092 12FD3E <he_mode_arm.hex> : 147456 samples line 11701 123809 1269A2 129420 12B5B7 12CEBB 12E191 12F092 12FD3E Hi, everyone, Sorry that hex files are too large for mail. So I quote a section of the he_mode.hex ( l3dec.exe generate) and he_mode_intel.hex , he_mode_arm.hex (mad v.0.14.2b generate) Best Regards, Pei-Lin Tsai

1 0

Bug in libid3tag
by Mark Malson 11 Oct '02

11 Oct '02

I have found that the function id3_render_paddedstring will crash if you are rendering a string that is longer (or exactly as long as) the length parameter you give it. Basically, length would be decremented to zero in the first loop and by the time it got to the second loop it wrapped around back to 0xFFFFFFFF. It is unsigned so a <=0 comparison won't help. I have changed two lines (marked below). Rob, if I read your code correctly I'm guessing you have somewhat of an antipathy toward "for" loops, so adapt as you see fit. - Mark Malson id3_length_t id3_render_paddedstring(id3_byte_t **ptr, id3_ucs4_t const *ucs4, id3_length_t length) { id3_ucs4_t padded[31], *data; int i; /* latin1 encoding only (this is used for ID3v1 fields) */ assert(length <= 30); data = padded; if (ucs4) { /* ** This line used to read: ** while (*ucs4 && length--) { */ for (i=0; (i<length) && *ucs4; i++) { *data++ = *ucs4++; if (data[-1] == '\n') data[-1] = ' '; } } /* ** This line used to read: ** while (length--) */ for ( ; i<length; i++) *data++ = ' '; *data = 0; return id3_latin1_serialize(ptr, padded, 0); }

3 5

Mac OS9 / CodeWarrior
by pmisteli 10 Oct '02

10 Oct '02

Hello, I have yet to find a MacOs9 player that uses mad. I found the latest Audacity but it sounds funny on my OS9 iMac. So I made my own MacOS9/Mad/iMAc player. It occurred to me that other people might be interested so I packaged libmad as a stand-alone CodeWarrior project, but have no idea how to release it, if anyone is indeed interested. The following describes what is currently packaged in a 240kb file libmadmac9.sit : /*************************************************************************** ** * README libmadmac9 * * libmad for Mac OS9 compiled with CodeWarrior * * Copyright (C) 2002 pmisteli * * This program is free software. you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation@ either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY, without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program@ if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * **************************************************************************** */ /* This is a CodeWarrior 5 project to generate libmadmac9.lib, a library for linking libmad with Mac OS9 apps built with CodeWarrior. It includes the libmad directory from the SourgeForge mad-0.14.2b release. Only two files from the SourgeForge release were slightly modified : - huffman.h - layer3.c The originals of these two files are included as huffmanORIG.h layer3ORIG.c. File libmadmac9Prefix.h specifies the FPM_64BIT build for libmad. This is just my way of building libmad with the compiler I have so that it works on my MacOS 9.1 iMac, and has not been tested with other compilers/machines. 8 October 02 - better late than never pmisteli(a)terpalum.umd.edu */

1 1

Updating tags in memory
by Mark Malson 08 Oct '02

08 Oct '02

I wrote this function (in Objective-C) to update the contents of a tag for writing out later. Am I on the right track? Do I need to update both the UTF8 and the latin strings? bool libid3tag_SetString (struct id3_tag const *tag, char const *id, NSString *newStr) { bool retVal = NO; struct id3_frame const *frame; id3_latin1_t *latin1; id3_utf8_t *utf8; /* text information */ union id3_field const *field; unsigned int nstrings, j; extern id3_ucs4_t *id3_utf8_deserialize(id3_byte_t const **ptr, id3_length_t length); if ((frame = id3_tag_findframe(tag, id, 0)) == nil) return NO; field = &frame->fields[1]; nstrings = id3_field_getnstrings(field); for (j = 0; j < nstrings; ++j) { id3_byte_t *ptr; id3_ucs4_t *ucs4; switch (field->type) { case ID3_FIELD_TYPE_STRINGLIST: ptr = [ newStr UTF8String ]; ucs4 = id3_utf8_deserialize (&ptr, [ newStr length ]); id3_field_setstrings (field, 1, &ucs4); free (ucs4); break; case ID3_FIELD_TYPE_LATIN1LIST: ptr = [ newStr cString ]; ucs4 = id3_latin1_deserialize (&ptr, [ newStr length ]); id3_field_setstrings (field, 1, &ucs4); free (ucs4); break; } } return YES; }

2 2

tag options
by Mark Malson 08 Oct '02

08 Oct '02

In writing out tags to a file I had trouble reading them back in using iTunes. I'm not EXACTLY sure why, but when I compared the id3v2.4 tags that iTunes generates vs. libid3tag, I found that libid3tag defaults to always using an extended tag header and writing out a CRC for each tag?? I'm not exactly sure what I'm talking about because I can't get to id3.org to get the latest spec, but that's another story. To fix it, I had to comment out everything in the "tag->options = " line in id3_tag_new, i.e., zeroing out the compression and CRC options. This prevented the extended header from being generated and it prevented the longer header from being generated on each tag. However, I know I'm disabling something that could be useful. Does anyone have any insight into this? I'd rather not flat out disable a feature in this lib.

2 2

Question about ID3v2.4 tags vs. older tags
by Mark Malson 08 Oct '02

08 Oct '02

All right, now for the questions. When libid3tag reads in a TYER tag (and other date/time tags) it coalesces them (at least when writing a v2.4 tag) into a TDRC tag. It appears that iTunes does not read the TDRC tag and prefers TYER, even in v2.4 tags. The comments in libid3tag say that TYER et al. are obsolete, but I'd like to go ahead and write them out anyway. Has anyone encountered this problem and maybe coded a workaround? My initial try was unsuccessful. Also, I would _love_ to read the id3v2.4 spec, (especially regarding TDRC vs. TYER) but www.id3.org has been down for quite some time. Is it gone? Does anyone have the spec that they could email me? Thanks, - Mark Malson

2 2

To parse ID3v2.4
by rahul_dsp 01 Oct '02

01 Oct '02

Hi All, I am new to the list ,I am working on ID3 tags decoding. I want to parse ID3v2.4 tag but facing lots of problems as basic idea of ID3v2.4 is not very much clear. Regarding SEEK Frame can anyone highlight how it works. What I know is that it gives the minimum offset of the next tag from the end of the current tag. This minimum offset is in synchsafe integers of four bytes does that mean that every 8th bit of the byte will be zero as was the case for size of tag and total bits will be 28 instead of 32. Please clear this out. Also I need sample tag of ID3v2.4 and ID3v2.2 or it would be great if someone provide me the link where it is available. regards, Rahul --------------------------------------------- http://mail.indiainfo.com India's first ISO certified portal Check world time at http://time.indiainfo.com

3 2

To parse ID3v2.4
by rahul_dsp 30 Sep '02

30 Sep '02

1 0

madplay frontend design
by Umar Qureshey 24 Sep '02

24 Sep '02

Hi, I would like to create a curses front-end for madplay 0.12.5b (I know it's ancient, I might migrate later to newer versions). My question is where in the code would this reside? Would it be in the main() function in madplay.c or perhaps play() in player.c? Looking at audio_*.c files, it seems that one can pass control commands to start, stop, etc. Any references or suggestions (regardless of madplay version) would be greatly appreciated. Regards, UQ

1 0

Also Need help with MAD Synthesis Polyphase Filterbank
by Jane Zhao 10 Sep '02

10 Sep '02

Hi, Sir, I also need help to understand your polyphase synthesis filterbank algorithm. I looked at your dct32 and synth_full funtions. They are quite different from the synthesis filter algorithm description in 11172-3. Is there any reference paper that descripes your algorithm? Thanks. -Jane On Tuesday, September 3, 2002, at 07:34 AM, Nelly.TOURNIER(a)wavecom.fr wrote: > I am now working on the MAD MP3 decoder, and I can't understand the > polyphase synthesis filterbank... Does anyone have some info please? What would you like to know about it? __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

1 1

MAD-polyphase filterbank synthesis
by Nelly.TOURNIER＠wavecom.fr 09 Sep '02

09 Sep '02

I don't really understand what does the mad_fixed_t filter[2][2][2][16][8] mean? What does each field exactly correspond to? What is the phase? Is it the subband number? And I can't see how the matrixing is made, with all the variables used, in the dct_32 function. Sincerely, Nelly

1 0

Need help with MAD Synthesis Polyphase Filterbank
by Nelly.TOURNIER＠wavecom.fr 03 Sep '02

03 Sep '02

I am now working on the MAD MP3 decoder, and I can't understand the polyphase synthesis filterbank... Does anyone have some info please? Thanks, Nelly

2 1

tremor relicensed as BSD (fwd)
by Nicolas Pitre 03 Sep '02

03 Sep '02

I thought this announcement could be of some interest to people here too. ---------- Forwarded message ---------- Date: Tue, 3 Sep 2002 14:24:48 +0100 From: rillian <rillian(a)telus.net> Reply-To: vorbis-dev(a)xiph.org To: vorbis-dev(a)xiph.org Subject: [vorbis-dev] tremor relicensed as BSD For those of you not of the commit mailing list, I wanted to point out that monty has checked the fixed-point 'tremor' vorbis decoder into xiph.org cvs, under the usual (free) xiph license. This was developed for use in embedded devices, so if you've been waiting for an interger-only (no fpu) implementation, you might want to give it a try. The code is in the 'Tremor' cvs module. As usual, nightly snapshots are available at http://xiph.org/ogg/vorbis/download/. There's also a new mailing list 'tremor(a)xiph.org'.

1 0

bug of show_status ?
by Zhiwen Yang 03 Sep '02

03 Sep '02

Is there anyone who knows why the static show_status function ? i changed this function to a global function and call it. I find the time in this function is right,such as the current time ,but i can not get it outside this function ? anyone knows this ?

1 0

how to get total time when play a mp3 using libmad
by Zhiwen Yang 02 Sep '02

02 Sep '02

Hi,everyone Is there a function that we can use to get a total time when we play a mp3 file using libmad. i printf the stats->total_time ,it is always zero ? Is there something wrong? Thanks

1 0

Re: mad-dev digest, Vol 1 #200 - 1 msg
by armin.gerritsen＠philips.com 29 Aug '02

29 Aug '02

> transmitter to a receiver. The present invention is distinguished by that > from the frequency coefficients of earlier and, if need be, future blocks, > a decision function is formed, on the basis of which the occurrence of an > error is determined, and that the frequency coefficient containing an > error is not longer utilized for the evaluation of subsequent blocks. Another insane pattent. Basicly this means that if you use any freqcuency coefficient to detect an error in coefficients in following blocks, you're screwed ... Of course you need to compare coefficients ... At least, I see no way to do proper error-correction in this area any other way. That they ever allowed such a pattent ... Armin

1 0

mp3 decoder patent licensing
by Joe Drew 28 Aug '02

28 Aug '02

So, Fraunhofer et al have decided to charge $0.75 per mp3 decoder. I am not positive on how this affects users of MAD, but I have a feeling that given the choice they would go after both people like me (users of MAD) and people like Rob (developers of mp3 decoders.) Rob, I sure hope the potentially forthcoming ogg decoder is similar to MAD's current interface. Maybe MAD could be Multi-format Audio Decoder? It'd be nice to have pluggable support in mpg321 for both codecs. -- Joe Drew <hoserhead(a)woot.net> <drew(a)debian.org> "This particular group of cats is mostly self-herding." -- Bdale Garbee

2 1

Development access
by Neil Hodge 20 Aug '02

20 Aug '02

Rob: Where can one get the latest sources? I noticed that you have FTP and a Sourceforge mirror set up, but I would assume these are not the latest (i.e., daily) development sources. Let me know. Thanks. -- Neil Hodge neh(a)attbi.com

1 0

Still waiting for help from Rob
by Kshitiz Malik 05 Aug '02

05 Aug '02

This is with reference to the mail I wrote a few days back, asking whether the first 9 bits of an mp3 file represent main_data_begin or main_data_end. Can somebody help me? Rob? __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

2 1

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

← Newer
1
...
14
15
16
17
18
19
20
...
28
Older →

Jump to page:

2025

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