Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: MP3 encoder/decoder?

  1. #1

    MP3 encoder/decoder?

    Hey people,

    I want to do a little audio project that involves cutting mp3's. Therefore I need not only a decoder but also an encoder. Does anyone know a good library? I prefer to use one single lib that can do both without too much hassle.

    Thanks.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  2. #2
    I've just looked at LAME:

    Download link

    But there's one thing I cant figure out. There is a pascal header in there, containing the following functions:

    Code:
    Function beInitStream(var pbeConfig: TBE_CONFIG; var dwSample: LongWord; var dwBufferSize: LongWord; var phbeStream: THBE_STREAM ): BE_Err; cdecl; external 'Lame_enc.dll';
    //Function beEncodeChunk(hbeStream: THBE_STREAM; nSamples: LongWord; pSample: PSmallInt;pOutput: PByte; var pdwOutput: LongWord): BE_Err; cdecl; external 'Lame_enc.dll';
    Function beEncodeChunk(hbeStream: THBE_STREAM; nSamples: LongWord; var pSample;var pOutput; var pdwOutput: LongWord): BE_Err; cdecl; external 'Lame_enc.dll';
    Function beDeinitStream(hbeStream: THBE_STREAM; var pOutput; var pdwOutput: LongWord): BE_Err; cdecl; external 'Lame_enc.dll';
    Function beCloseStream(hbeStream: THBE_STREAM): BE_Err; cdecl; external 'Lame_enc.dll';
    Procedure beVersion(var pbeVersion: TBE_VERSION); cdecl; external 'Lame_enc.dll';
    However, there's also an include directory in the archive, containing a C++ header. I quickly scanned through it and I found out that it enables you to decode MP3 aswell. For example:

    Code:
    /* required call to initialize decoder */
    hip_t CDECL hip_decode_init(void);
    
    /* cleanup call to exit decoder  */
    int CDECL hip_decode_exit(hip_t gfp);
    
    int CDECL hip_decode( hip_t           gfp
                        , unsigned char * mp3buf
                        , size_t          len
                        , short           pcm_l[]
                        , short           pcm_r[]
                        );
    
    /* same as hip_decode, and also returns mp3 header data */
    int CDECL hip_decode_headers( hip_t           gfp
                                , unsigned char*  mp3buf
                                , size_t          len
                                , short           pcm_l[]
                                , short           pcm_r[]
                                , mp3data_struct* mp3data
                                );
    Just wondering why the pascal header doesn't have these defs. Is there any translation somewhere?

    Thanks
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  3. #3
    I'm not aware of any newer units, but it looks like those are newer versions of some lame_decode_* functions

    But should be easy enough

    Code:
    type
     lameInt = longint; // Use cint from ctypes in fpc, or smallint on linux
     
     mp3data_struct = packed record
      header_parsed,
      stereo,
      samplerate,
      bitrate,
      mode,
      mode_ext,
      framesize: lameInt;
      
      nsamp: longword;
      
      totalframes,
      framenum: lameInt;
     end;
    
    function hip_decode_init: pointer; cdecl; external 'Lame_enc.dll';
    function hip_decode_exit(gfp: pointer): longint; cdecl; external 'Lame_enc.dll';
    function hip_decode(gfp: pointer; mp3buf: pointer; len: longint; PcmL, PcmR: pword): longint; cdecl; external 'Lame_enc.dll';
    function hip_decode_headers(gfp: pointer; mp3buf: pointer; len: longint; PcmL, PcmR: pword; var mp3data: mp3data_struct): longint; cdecl; external 'Lame_enc.dll';
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  4. #4
    Thanks.

    I'm not very good at porting C(++) yet. I'm afraid to make subtle mistakes that will cost me hours of my precious time to fix. Well, maybe I should just try it someday.

    As you may expect: The actual header is way bigger that that sample. About 1200 lines. It might be good to have a pascal version of it. However, the decode functionality of LAME is based on mpg123 code that was released under GPL, so some people may want to go down other paths instead.

    Thus far, I think that using mpg123 for decoding and LAME for encoding might be "easiest". I can also attempt a header port and use LAME for both encoding and decoding.

    Does anyone know any alternatives? I'm sure I have more options, but I'd like to know more of them.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  5. #5
    You could write a decoder yourself...

    That might be a too big undertaking. I'm not well aware of any other good decoders

    I would write one if it wasn't so hard to get my hands on a real and complete specification. Just for the sake of getting rid of irritating semi-crossplatform dependencies. I got MP1 working, but I haven't even been able to test it since I can't find an encoder for it...
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  6. #6
    lol. This supposed to be a project for a few weeks, so writing my own decoder is out of the question.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  7. #7
    mpg123 is a excellent decoder, but you should stick with lame, it's both a encoder and decoder.
    From brazil (:

    Pascal pownz!

  8. #8
    I agree. Using one lib is nicer. But do you have those headers that let me use the encode functionality of LAME?
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  9. #9

  10. #10
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Erm... I've been following this thread quite closely since I find it may be extremely useful for some of my code - so I looked into the above link and can I just say that if you use a platform that has the Windows unit, like windows, all is nice. However, on linux I noticed that by default there is no Libc supplied with FPC (or at least not this version) so i tried a few of the units that are suggested by the FPC wiki to replace it and no luck. Any solutions for us non-windows folk?

    Just a thought but unless I'm missing something here (other than clib) this is quite annoying =p

    Edit: aaahahaaaa... Found the linking error:

    As it happens on fpc 2.4.0, Libc is NOT compiled and its in
    Code:
    /usr/share/fpcsrc/2.4.0/packages/libc/src/
    now thats nice, but that folder is protected - you have to sudo or gksudo to modify stuff there. If you use an IDE such as geany or fp and don't sudo or gksudo then it tries to compile LibC - fails and then tries to read LibC and fails and thus says there is no LibC. Annoying.

    Or alternatively, I'm told you can go to http://sourceforge.net/projects/freeclx/ and get the kylix utils there. They should also contain LibC as part of gLibC... Sorry for the unnecessary post, but some may find this useful.

    Final Edit: And if you sudo it, you still get some errors while linking ending in a super massive epic fail. Solution: Copy ALL files from libc folder to same folder you have lame.pas and compile it. Should work with less complaints... Don't know if you all have to go through this but this seems to be the only solution I have found on Ubuntu 10.10 Maverick with latest updates (all update sources except unsupported)
    Last edited by code_glitch; 10-12-2010 at 06:27 PM.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL