toolame-devel Mailing List for toolame (Page 2)
Status: Alpha
Brought to you by:
mikecheng
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(2) |
Mar
(8) |
Apr
|
May
(25) |
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(4) |
Dec
(3) |
2005 |
Jan
|
Feb
(6) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Jesse S. <sc...@gm...> - 2004-07-30 19:39:46
|
To answer my own question, and scold myself, www.cartchunk.org has a nice little app called waveview that can view .wav file header information from prophet system's output. I found this in a thread in this very mailing list, imagine that!!!. I'm still slogging through to find info on parallel output, and mp2 input however. On Thu, 29 Jul 2004 17:50:47 -0400, Jesse Schoch <sc...@gm...> wrote: > Firstly, I have very little C programming experience, and very little > experience with audio. I do have a good background in java, *nix, and > perl, so please forgive me if these questions are obvious and please > let me know if there is a better forum in which to ask. > > I have a requirement to do some encoding from .wav file that is > encoded in a .wav format to several outputs: > .mp2 (mpeg audio layer 2 256Kbit/s CBR) > .wav (mpeg 2 same CBR and bitrate) > .mp3 (I can use lame for this). > > Xdelta shows that there is only a very small difference between the > .wav and .mp2 files, I assume only the frame headers. and the id3 tag > > The source file is from a proprietary format (Prophet Systems) which > has the .wav file, a ASCII .dat file containing track information, and > a binary .vid file. I have no clue what the .vid file is, and I'd > very much like to know. Our current process uses 3rd party software > that takes the .wav and serialy processes the different outputs. > > What I'd like to know is > > 1. How can I figure out what format the source file is. Is there a > header reader out there I can download and compile? I've read the > specs on the MPEG frame header, but I don't have much experience > dealing with binary file formats. > > 2. Can I process 1 frame of the input file and output the 3 different > format framse to my 3 output files in parallel (threaded). I realize > that this only saves me the overhead of the initial read but I'd have > to guess it would improve my transcoding time. > > Any help/feedback is appreciated > |
From: Jesse S. <sc...@gm...> - 2004-07-30 16:14:43
|
I've been having lots of problems with noise in my output. see below. Snip, snip > > Batch converting is trivially simple on Linux -- it just takes a little shell > scripting. Something like: > > #!/bin/bash > for i in /some_dir/*.wav; > do toolame -m s -b 256 "$i"; > done I did quite a bit of expirimentation last night (I actualy got past research and started building ) but I could not output an acceptable quality file. I grabbed libmad (a high quality decoder ???) and libmad-dev with my friendly apt-get, I also grabbed madllb which should output pcm from a .wav file. The problem was that though I could create an acceptable sounding .aiff file with madlld and sox, I could not do the same with toolame and your patch (didnt' try without your patch). Generating the .aiff file with madlld ./madlld < This_land_is_your_land.mp2 |sox -r 44100 -t cdr - test.aiff madlld: 256000 kb/s audio MPEG layer II stream without CRC, normal LR stereo with no emphasis at 44100 Hz sample rate madlld: end of input stream madlld: 7299 frames decoded (3:10.667). Various toolame attempts ./madlld <This_land_is_your_land.mp2| toolame -t 2 -p 2 -v 10 -s 44.1 -e -b 256 -W - out.mp2 -------------------------------------------- Input File : 'stdin' 44.1 kHz Output File: 'out.mp2' 256 kbps MPEG-1 Layer II stereo Psycho model=2 (Mode_Extension=0) [De-emph:Off Copyright:No Original:No CRC:On] [Padding:Off Byte-swap:Off Chanswap:Off DAB:Off] VBR Enabled. Using MNR boost of 10.000000 ATH adjustment 0.000000 -------------------------------------------- encode_init: using tablenum 1 with sblimit 30 madlld: 256000 kb/s audio MPEG layer II stream without CRC, normal LR stereo with no emphasis at 44100 Hz sample rate absthr[][] sampling frequency index: 1 madlld: end of input stream madlld: 7299 frames decoded (3:10.667). Hit end of audio data VBR stats: 32 48 56 64 80 96 112 128 160 192 224 256 320 384 0 0 0 0 0 0 0 0 0 52 116 67 7064 0 Avg slots/frame = 1034.129; b/smp = 7.18; bitrate = 316.702 kbps Done toolame -b 256 test.aiff outMP2.mp2 >>> Using Audio IFF sound file headers Parsing AIFF audio file >>> 44100.000000 Hz sampling frequency selected -------------------------------------------- Input File : 'test.aiff' 44.1 kHz Output File: 'outMP2.mp2' 256 kbps MPEG-1 Layer II j-stereo Psy model 1 [De-emph:Off Copyright:No Original:No CRC:Off] [Padding:Normal Byte-swap:Off Chanswap:Off DAB:Off] ATH adjustment 0.000000 -------------------------------------------- encode_init: using tablenum 1 with sblimit 30 [2200]] Hit end of audio data Avg slots/frame = 835.918; b/smp = 5.80; bitrate = 256.000 kbps Done |
From: Fred G. <fr...@sa...> - 2004-07-30 00:46:57
|
On Thursday 29 July 2004 17:50, Jesse Schoch wrote: > Xdelta shows that there is only a very small difference between the > .wav and .mp2 files, I assume only the frame headers. and the id3 tag > > The source file is from a proprietary format (Prophet Systems) which > has the .wav file, a ASCII .dat file containing track information, and > a binary .vid file. I have no clue what the .vid file is, and I'd > very much like to know. Our current process uses 3rd party software > that takes the .wav and serialy processes the different outputs. I posted a patch against toolame-02l about a year that adds what I suspect is precisely the capability you're talking about here --i.e. generate an MP2-encoded .WAV file with the proper BWF-compliant header chunks that Prophet requires. You can get it at: ftp://ftp.salemradiolabs.com/pub/srlabs/toolame-02l-patch-fredg01.gz This was in order to support use with the Rivendell Project: http://www.salemradiolabs.com/rivendell/ BTW, the MP2-encoded WAV file isn't a proprietary format, but follows an EBU (European Broadcasting Union) standard known as 'Broadcast Wave File', or 'BWF' for short. You can find the full spec at: http://www.sr.se/utveckling/tu/bwf/ Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs | |-------------------------------------------------------------------------| | Never worry about theory as long as the machinery does what it's | | supposed to do. | | -- Robert A. Heinlein | |-------------------------------------------------------------------------| |
From: Jesse S. <sc...@gm...> - 2004-07-29 22:50:53
|
Firstly, I have very little C programming experience, and very little experience with audio. I do have a good background in java, *nix, and perl, so please forgive me if these questions are obvious and please let me know if there is a better forum in which to ask. I have a requirement to do some encoding from .wav file that is encoded in a .wav format to several outputs: .mp2 (mpeg audio layer 2 256Kbit/s CBR) .wav (mpeg 2 same CBR and bitrate) .mp3 (I can use lame for this). Xdelta shows that there is only a very small difference between the .wav and .mp2 files, I assume only the frame headers. and the id3 tag The source file is from a proprietary format (Prophet Systems) which has the .wav file, a ASCII .dat file containing track information, and a binary .vid file. I have no clue what the .vid file is, and I'd very much like to know. Our current process uses 3rd party software that takes the .wav and serialy processes the different outputs. What I'd like to know is 1. How can I figure out what format the source file is. Is there a header reader out there I can download and compile? I've read the specs on the MPEG frame header, but I don't have much experience dealing with binary file formats. 2. Can I process 1 frame of the input file and output the 3 different format framse to my 3 output files in parallel (threaded). I realize that this only saves me the overhead of the initial read but I'd have to guess it would improve my transcoding time. Any help/feedback is appreciated |
From: Thomas R. <th...@th...> - 2004-03-27 21:31:34
|
... by studying the gcc-manpage and removing the know known as Intel-specific -march options/variables. You should mention this in the README file, for the source compiles clean and stable under Darwin. No problems seen so far, output files sound good. Sincerly, Thomas Rix |
From: David F. <df...@su...> - 2004-01-26 09:26:25
|
I am trying to compile toolame 2.0k on a Windows XP/Cygwin gcc compiler (3.3.1-3). I downloaded the source, changed the Makefile (arch=3Dpentium4), and ran "make". I am getting the following errors during the ld phase: "Undefined reference to __sincos" Cygwin has the gcc compiler and gcc source files. A partial cygcheck -c : gcc 3.3.1-3 OK gcc-g++ 3.3.1-3 OK gcc-mingw 20030911-4 OK gcc-mingw-core 20031020-1 OK gcc-mingw-g++ 20031020-1 OK gdb 20030919-1 OK Obviously, my setup is not correct for whatever the __sincos tweak is = doing. Any hints on how to compile, or what else I need to install to make this work? Thanks =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= David Fannin df...@su... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 |
From: Otto B. <of...@ho...> - 2003-10-09 23:35:17
|
Hi, The version of tooLAME 02l (2-Mar-2003) does not generates audio files compatible with TMPGEnc plus. I was using the CYGWIN compiled version for dos/win. Since I did not find any place else to report this problem I decided to try here. Regards, Otto. _________________________________________________________________ ¿Estás buscando un auto nuevo? http://www.yupimsn.com/autos/ |
From: Steve S. <st...@pr...> - 2003-08-26 02:42:16
|
Markus Jonsson created a DLL from Toolame 0.2l. He told me the following: "I built a simple wrapper around the tooLame 0.2l code. That was the easy part. The hard part was to get rid of all memory leaks in it... (tooLame never frees any memory it has allocated, expecting that the program should only be run once so the OS will clean up any allocated memory)." You can download it here: http://www.prx.org/src/tooLameF-src-02l.zip There is a Readme included with it, which begins: "tooLameF.dll is a DLL implementation of parts of the tooLame MPEG layer II encoder. It has been modified in order to remove numerous memory leaks, to allow multi-threaded execution, and to provide a C-compatible DLL interface. The 'F' in the DLL name is intended to indicate that it is a floating point input version of tooLame." Mike, if you'd like to post it on your site, that might be more reliable. Cheers, Steve -- Steve Schultze, st...@pr... Technical Manager, The Public Radio Exchange http://www.prx.org |
From: Bradley J. <te...@ma...> - 2003-08-23 01:52:46
|
I have a DIVX file with AC3 audio. I try to use tooLAME with TMPGEnc Plus and All I get is a roughly 700MB *.wav file with no sound. If I open up the *.wav file with Nero's Wav Editor it looks pretty blank. Can anyone help me? Thanks ahead for the help. --Brad |
From: mike <mik...@pl...> - 2003-07-28 14:46:12
|
Hi all, =09toolame is now a library (I've only tested it as a static library, but= I=20 think it should be possible to build it as dynamic. Not sure why you'd re= ally=20 want to just yet). It's up on the website. The following is my ramble of= =20 stuff that needs to be said or done before a proper 02m is released. * Running 'make' in the root dir should compile the library, the normal=20 'toolame' executable and a *very* simple 'stoolame' application. * The directory structure has changed. There is now libtoolame/ =20 =09- this is where the library code is frontend/ =09- this is where the code for the familiar 'toolame' frontend is simplefrontend/ =20 =09- This is a severly cut-down version of the frontend which does the mi= nimum=20 you need to do to open the library, encode some audio and close the libra= ry. * See "libtoolame/toolame.h" for what is exposed to the user. =20 * The "toolame_options" structure contains *everything* at the moment=20 (including all dynamically allocated buffers and values for the psycho=20 models). This is a bit kludgy and it will probably change.=20 * There is still some memory that isn't mallocd/freed correctly, so with=20 multiple calls to toolame_init()/toolame_deinit() there'll be some defini= te=20 leakage. [besides a few bugs with MPEG2-LSF bitrate selection, this is t= he=20 only thing in the code that I really want to do before 02m goes out] * Thanks to Chris there's an RPM spec, but I haven't had the brainpower t= o=20 have a go at making it work with the changed dir structure. * The DAB stuff is broken, Nicolas. The library itself isn't guaranteed = to=20 remember any previous frames, so writing the DAB CRC information into the= =20 previous audio frame is no longer possible. I think all the necessary pi= eces=20 are there for it to be reimplemented *in the frontend*. The frontend wil= l=20 just have to have two buffers for mp2 audio and write the CRC information= =20 into the previous buffer before saving it. * The build system is a very basic. I would *very strongly* like to keep= a=20 simple "make" based build system. I appreciate that the autoconf tools a= re a=20 small blessing to the end user - but at the moment there only seems to be= =20 about 10 of them, so I'm not too worried. * I would like to get it building semi-nicely under Visual Studio. * If you felt like working on a BWF-compliant encoder now would be a grea= t=20 time to start. Add a BWF flag to the frontend_options in frontend/fronte= nd.c=20 and add some routines to write the BWF header and wrap the mp2 audio prop= erly=20 before flushing it to file. that's all that's in my brain for the moment michael. |
From: Nicolas C. (C. G. 90,8) <nic...@br...> - 2003-07-19 05:36:00
|
At 11:25 19/07/2003 +1000, mike wrote: >I've definitely broken the DAB stuff in the 02m beta'ing. Just wondering if >anyone actually uses it? I'm looking through the ETSI standard to see what >has to be in the frame, but it's a bit obtuse. > >Nick, you still out there? Hello, Yes we use it !!!! In the DAB specs, there is two parts : the CRC part, the CRC is calculate on some parts of the audio frame and this CRC is put at the end af the precedent frame (as I remember). the second option permit to put some blank at the end of the frame to eventually put datas with an external application, this will be very important when toolame will be in library. Bye. +-------------------------------------------+ | E-mail : Nic...@br... | | URL : http://www.annuaire.fr.fm/ | +-------------------------------------------+ |
From: mike <mik...@pl...> - 2003-07-19 01:23:55
|
I've definitely broken the DAB stuff in the 02m beta'ing. Just wondering = if=20 anyone actually uses it? I'm looking through the ETSI standard to see wh= at=20 has to be in the frame, but it's a bit obtuse.=20 Nick, you still out there? mike |
From: mike <mik...@pl...> - 2003-06-01 03:11:03
|
Hi all,=20 =09If you find the urge to code, you could add sample rate conversion to = the=20 frontend using: libsamplerate http://www.mega-nerd.com/SRC/api.html #ifdef everything so that it compiles cleanly without it. just a suggestion mike |
From: mike <mik...@pl...> - 2003-05-31 23:45:13
|
Hi all, =09Just a minor cleanup before I drop into exam mode for a couple of week= s. (http://www.planckenergy.com/layer2/toolame-02m-b4.tar.gz - or follow the= =20 "beta" link from the main page) * Cleaned up some headers (plenty more to go) * options structure is now 'tooLame_options' * there are tiny libraries for pcm/wav/aiff reading for the basic fronten= d. A selection of possible small projects you may wish to attempt: * fix the libwave.c/h to properly read simple WAV chunks. * patch frontend.c to nicely handle stdin (a small libstdinaudio.c like t= he=20 libwave/pcm/aiff might do the job) * write a new frontend which uses libsndfile instead of libpcm/wav/aiff. * write a new psy model :) later mike |
From: Fred G. <fr...@sa...> - 2003-05-30 01:17:41
|
On Thursday 29 May 2003 09:27, mike wrote: > Fred: I'm sorry, but the bitstream.c changes will affect your BWF patch ( > which I've totally neglected). To fix: I'll rename all my buffer based > bit-filling functions and plonk them in a new file (bitbuffer.c). But > you'll still need to rework the code into a teeny library-style file and > put it in the front end. I still want to include it in the main dist > tarball. No problem. I'll re-integrate it after the dust settles from the library work. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | Never worry about theory as long as the machinery does what it's | | supposed to do. | | -- Robert A. Heinlein | |-------------------------------------------------------------------------| |
From: Fred G. <fr...@sa...> - 2003-05-30 01:14:10
|
On Thursday 29 May 2003 07:54, mike wrote: > The 02m-b2 version of toolame now has the library functionality working - > at least there's an API to work with. The frontend is now: > > myoptions = tooLame_init(); > tooLame_init_params(myoptions); > while ( (num_samples = audio_get_simple(infile, left, right)) != 0 ) { > frames += tooLame_encode_buffer(myoptions, left, right, num_samples, > mp2buffer, mp2buffer_size, &mp2fill_size); > fwrite(mp2buffer, sizeof(unsigned char), mp2fill_size, outfile); > } > tooLame_encode_flush(myoptions, mp2buffer, mp2buffer_size, > &mp2fill_size); fwrite(mp2buffer, sizeof(unsigned char), mp2fill_size, > outfile); } > > where: > - short int leftpcm[] (left audio channel) > - unsigned char mp2buffer[] (where the mpeg data gets put) > - int mp2buffer_size (how much space the user alloted to the buffer) > - int mp2fill_size (how much mpeg data the library has put in the buffer) > - int num_samples (how many audio samples per channel is in the pcm > buffers) Could I make the following suggestions: 1) Rename the 'options' structure to 'tooLame_options' 2) Change 'tooLame_options.sampling_frequency' to be the actual sampling frequency (in samples/sec), rather than indices into a table. We should try to hide the whole MPEG samplerate/bitrate indexing thing from the user as much as possible. If the calling program specifies an invalid samplerate/bitrate, then we simply return an error out of tooLame_init_params(). 3) Remove the 'tooLame_options.verbosity' field. 4) Remove the 'tooLame_options.num_samples' field. 5) Change the declaration of tooLame_init() to be: void tooLame_init(tooLame_options *opts) This would make things much friendlier for C++ programmers, as it would make this call compatible with the STL. (Yes, it also means the application programmer would have to manage the memory for that struct himself). 6) Return a small integer handle from tooLame_init_params() that would then be used for subsequent calls to tooLame_encode_buffer(), tooLame_encode_flush() and tooLame_deinit(), in place of passing in a tooLame_options. This will be needed to make the library thread-safe. All-in-all, things are looking very promising. As soon as you're happy with the state of the API, I'd like to have a go at making a build configuration that would give us a shared lib object. Thanks for all the hard work you put into tooLAME. Good luck on exams. :) Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | Yet it is not our part to master all the tides of the world, but to do | | what is in us for the succour of those years wherein we are set, | | uprooting the evil in the fields that we know, so that those who live | | after may have clean earth to till. | | -- J.R.R. Tolkien | | "The Lord of the Rings" | |-------------------------------------------------------------------------| |
From: Fred G. <fr...@sa...> - 2003-05-30 00:46:02
|
On Thursday 29 May 2003 02:42, you wrote: > Had to update autoconf (2.57). Mandrake 9.0 ships with 2.13 (which is quite > old). Interesting. So does Red Hat, last I looked (somewhere around 8.0). It was one of the many reasons I ended up standardizing on SuSE for development work. I wonder if there's something in those distros that *require* the use of such an antique version. > > Use the new arctangent implementation (default is *not* to use the new > > Just wondering - is there any reason you decided to not make this default? > Have you found issues with the new atan stuff? No issues. I did it mainly to provide an example of how to make a compiler flag configurable from the command line. Feel free to remove it if the new atan is stable. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | Some people call them "cars" or "trucks"; I call them "dimensional | | transmogrifiers" because they change three-dimensional cats into | | two-dimensional ones. | | -- F. Frederick Skitty | |-------------------------------------------------------------------------| |
From: mike <mik...@pl...> - 2003-05-29 13:26:16
|
Hi all, =09Well, here endeth my little burst of work for a while. Exams start nex= t week=20 so I suppose I'll have to start preparing. http://www.planckenergy.com/layer2/toolame-02m-b3.tar.gz (or follow the b= eta=20 link on the page) =09The code is "mostly" functional. Some of the old command line switches= don't=20 do anything (e.g. the "downmix" switch. but it shouldn't be hard to fix),= but=20 everything seems to be working just as before. =09Thanks to Fred it now compiles via: configure, make =09All the frontend is now done. There's a small libpcm, libaiff, and lib= wave=20 which handle the parsing of headers for these files. The WAV parsing is j= ust=20 as dodgy as it was before, but now it's in a neat little file of its own = -=20 someone please hack on it so that the WAV chunks are properly handled.. =09The bitstream handling had to be changed a bit, so that the library wo= rked=20 with buffers, rather than assuming it had a file to play with. Fred: I'm sorry, but the bitstream.c changes will affect your BWF patch (= =20 which I've totally neglected). To fix: I'll rename all my buffer based=20 bit-filling functions and plonk them in a new file (bitbuffer.c). But you= 'll=20 still need to rework the code into a teeny library-style file and put it = in=20 the front end. I still want to include it in the main dist tarball. Code is still a shamozzle. There are a few functions in there that can s= till=20 be called that shouldn't be. There are redundant parameters *everywhere*.= =20 There are globals by the bugload. There is no sanity check that the optio= ns=20 that are finally passed to the encoder aren't completely bogus. ToDo: - think of a way to standardise the error reporting - stomp out those globals later mike |
From: mike <mik...@pl...> - 2003-05-29 11:53:09
|
HI all, =09[Accidently sent this reply to Fred only] On Wednesday 28 May 2003 12:50 pm, Fred Gleason wrote: > Once that's done, it's possible to build and install things with the > familiar: > =09./configure > =09make > =09make install Had to update autoconf (2.57). Mandrake 9.0 ships with 2.13 (which is qui= te old). If it barfs, there's still the "Makefile.unix" so you can still "m= ake -f Makefile.unix" > To generate a distribution tarball, simply do 'make dist' after 'make'. Did that. Now the latest tarball is up on planckenergy.com (it's the link marked "beta 29 May" - http://www.planckenergy.com/layer2/toolame-02m-b2.tar.gz > =09=09Use the new arctangent implementation (default is *not* to use th= e new Just wondering - is there any reason you decided to not make this default= ? Have you found issues with the new atan stuff? The 02m-b2 version of toolame now has the library functionality working -= at least there's an API to work with. The frontend is now: myoptions =3D tooLame_init(); tooLame_init_params(myoptions); while ( (num_samples =3D audio_get_simple(infile, left, right)) !=3D = 0 ) { frames +=3D tooLame_encode_buffer(myoptions, left, right, num_sampl= es, mp2buffer, mp2buffer_size, &mp2fill_size); fwrite(mp2buffer, sizeof(unsigned char), mp2fill_size, outfile); } tooLame_encode_flush(myoptions, mp2buffer, mp2buffer_size, &mp2fill_size); fwrite(mp2buffer, sizeof(unsigned char), mp2fill_size, outfile); } where: =09- short int leftpcm[] (left audio channel) =09- unsigned char mp2buffer[] (where the mpeg data gets put) =09- int mp2buffer_size (how much space the user alloted to the buffer) =09- int mp2fill_size (how much mpeg data the library has put in the buff= er) =09- int num_samples (how many audio samples per channel is in the pcm bu= ffers) Anyone forsee problems with that API/datatypes ? To Do: - the wave/aiff routines into libraries and then part of the frontend - code cleanup (which never seems to end) later mike ------------------------------------------------------- |
From: Fred G. <fr...@sa...> - 2003-05-28 14:11:45
|
On Wednesday 28 May 2003 06:35, mike wrote: > Had to be run twice on my system. Due to some cryptic issues with aclocal > it barfed on the first run. > > This is one of the things that bugs me about autoconf. weird arse errors. > Often an update to the latest autoconf/make helps. A second run worked > fine. "Cryptic" describes it well. It can be (and sometimes is, for me) absolutely infuriating. The way I see it though, the point of the Autotools is to make life much simpler for the end users, at the expense of greater complexity for the maintainers. I don't think that's an unreasonable tradeoff, but it's cold comfort when you're sitting staring at a CRT at 0230 wondering why the @#%@% thing is throwing some bizarre error. > > make > > Barfs with: > Makefile:204: ath.Po: No such file or directory > Makefile:205: audio_read.Po: No such file or directory > etc for every file. Hmm. What version automake are you running? Sounds like an update may be in order. The config was developed using Automake 1.6.3 and Autoconf 2.53. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | The fountain code has been tightened slightly so you can no longer dip | | objects into a fountain or drink from one while you are floating in | | mid-air due to levitation. | | Teleporting to hell via a transportation trap will no longer | | occur if the character does not have fire resistance. | | -- README file from the "NetHack" game | |-------------------------------------------------------------------------| |
From: mike <mik...@pl...> - 2003-05-28 10:34:20
|
Thanks Fred On Wednesday 28 May 2003 12:50 pm, Fred Gleason wrote: > =09autoreconf Had to be run twice on my system. Due to some cryptic issues with acloca= l it=20 barfed on the first run. This is one of the things that bugs me about autoconf. weird arse errors.= =20 Often an update to the latest autoconf/make helps. A second run worked f= ine. > =09./configure Seems to go okay. > =09make Barfs with: Makefile:204: ath.Po: No such file or directory Makefile:205: audio_read.Po: No such file or directory etc for every file. later mike |
From: Fred G. <fr...@sa...> - 2003-05-28 03:16:51
|
Attached is a patch against tooLAME-02m-b1. It reconfigures the build system to use Autoconf and Automake The patch puts the source tree into a "maintainer-clean" state --i.e. you'll need to generate the 'configure' script by doing the following from the top of the source tree (you'll need Autoconf and Automake installed on the system for this to work): autoreconf Once that's done, it's possible to build and install things with the familiar: ./configure make make install To generate a distribution tarball, simply do 'make dist' after 'make'. In addition to the standard options (do './configure --help'), there are some tooLAME-specific arguments that can be passed to the configure script, as follows: --enable-atan Use the new arctangent implementation (default is *not* to use the new code) --enable-debug Build with debug support (default is currently *not* to build debug support) --target=<arch> Where <arch> is one of the following: i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp (Default is to use the local compiler default settings) Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20186 | |-------------------------------------------------------------------------| | There is a certain combination of discipline and anarchy | | in the way I work. | | --Robert DeNiro | |-------------------------------------------------------------------------| |
From: Steve S. <st...@pr...> - 2003-05-27 19:38:37
|
On 5/27/03 2:04 AM, "mike" <mik...@pl...> wrote: > On Tuesday 27 May 2003 09:57 am, Fred Gleason wrote: >> On Monday 26 May 2003 17:56, mike wrote: >>> I was trying to think what's the best way to pass in/out the sound/mpeg. >>> At the moment, I just pass in the inputfilename and the outputfilename. I >>> let the toolame library open them, read/write and then close. >> >> I don't think this is general enough. We can't assume that the data >> source/end points will be files -- they could be sockets, pipes, LADSPA >> plugins, JACK ports -- you name it. > Yeah, that was just a statement of what it does "at the moment". Until I > figure out just exactly *what* i'm going to pass to the encoder. As I > mentioned, probably a pointer to a buffer of input audio samples, a count of > the number of the samples in the buffer, and a pointer to the buffer of mpeg > frames returned. > >>> It'd be preferable to have the frontend handle the reading, as then it >>> could read any file format it has a library for, resample it, downmix it, >>> warp it. >> I don't think we'd want/need functionality like this in the front end at > I was trying to say that *if* you wanted those things in a frontend you > *could* have them. I.e. disassociated the file reading from the file > encoding. The frontend *can* do whatever the hell it wants with the input > samples, just so long as, in the end, a buffer of audio gets passed to the > encoder. I agree, and clarify that it would be great if the frontend had hooks for external libraries for reading and writing (libsndfile would be a natural first choice). >> a minimal (but correct) PCM wav implementation, plus the ability to encode >> raw PCM data > This is all I'm aiming for in the vanilla tooLame frontend. Oops. Didn't mean to repeat this suggestion in my last email. Obviously I agree. >> (the quesiton of AIFF support I defer to others -- personally, I have no >> use for it). > If no one pipes up in the near future, it's gone. Any Mac users out there who > can confirm/deny the use of AIFF on their platform? It's still the standard and is the default linear format in iTunes for OS 9 and OS X. However, it might make more sense to build a solid frontend which can have libraries plugged in for AIFF, rather than build AIFF into the frontend directly. Speaking of which, if the end user decides to use libraries that support WAV reading, then when a WAV conversion is requested, it makes sense that the library should take care of reading it and feeding it to toolame, rather than allowing tooLame to do it's native WAV reading (same for AIFF, if that's in the frontend). Mike also wrote: > I'm just trying to figure out the nuts+bolts of it, and how it'd be best to > write it such that it'd be a general interface. I'm thinking the frontend > program does something more like this: > while (more_audio_data) { > read_some_audio(from_a_file) > mpeg_audio_buffer *tooLame_encodeChunk(pointer_to_buffer. > length_of_audio_in_buffer) > OR > int bytes_in_mpeg_audio_buffer tooLame_encodeChunk(inbuffer, length of > audio, outbuffer) > } I just want to verify that this would work for audio input of undetermined length (raw PCM, piped input, etc.) Also, anyone know the affect on Macintosh OS 9 support if toolame uses autotools? I know, it doesn't compile on OS 9 NOW, but in my dream world it would. Probably no one here has experience with OS 9. Regards, Steve -- Steve Schultze, st...@pr... Technical Manager, The Public Radio Exchange http://www.prx.org |
From: Steve S. <st...@pr...> - 2003-05-27 19:06:46
|
Let me first say thanks to Mike for all his great work on tooLame. I'll try to reasonably explain some of my thoughts and give whatever help I can offer with my meager skills. >>> Why not just use libsndfile? It's proven, cross-platform, and supports >>> more formats. LAME already can be compiled to use it. >> >> Perhaps the better strategy here would be to see >> if Erik would be interested in adding this support, rather than hacking it >> into tooLAME piecemeal. > > Hmmm. I feel i should speak up here on the direction of toolame. I actually > *like* toolame's build process and audio loading. It's simple. dead simple. > (so simple it breaks on weird stuff). But then it doesn't rely on 3 different > other libraries to read every format under the sun. neither does toolame > serve/render webpages, nor does it read email. > > As you all may have gathered from joining the lowest volume mailing list on > the planet, I'm *not* trying to put everything under the sun into toolame. > > Having said that, I *am* interested in having functionality that is actually > useful to people who use layerII encoding on a regular (or even professional > basis). (NOTE, after reading your comments on toolame 4.0 below, I think you're saying pretty much the same thing, but I'll leave my comments in.) Good points. I think it would be a waste of time to try to put as many file formats as possible into toolame itself. You could keep the compile simple, and perhaps support only vanilla WAV PCM. However, if you could make it so that libsndfile could be optionally included/linked (similar to how LAME does it) then someone who needed additional file formats could change that compile flag and find whatever libraries they need. Toolame would have to support only one audio format and an audio loading library API, with someone else doing the hard work of supporting each NWAAF*. For example, the libsndfile API is here: http://www.zip.com.au/~erikd/libsndfile/api.html Maybe we could even grab the WAV PCM loading code from libsndfile and copy-paste it into the toolame code, with Erik's permission. A similar optional compile flag could include resample libraries. Again, Erik has defined an API just for this purpose: http://www.mega-nerd.com/SRC/api.html Each of those libraries could essentially sit "in front" of the toolame code, and simply feed it the audio it expects after doing whatever necessary conversions. Each of Erik's libraries above appear to be highly cross-platform. >>> On a more general level, why not structure the code base of tooLame like >>> LAME? > How much time do you have? Ok, my comment was a bit aggressive. What I was trying to say was that it might make sense to structure toolame in such a way that the codec could be plugged into a more multipurpose application like LAME. I don't fully understand the structure of the LAME code base, but somewhere in there is a Layer III codec (perhaps not as abstracted as would be ideal, and split up between lame.c, encoder.c, and a few others). Subtract the Layer III codec, and you have a lot of useful wrapper code (option handling, dll wrappers, acm wrappers, library support, etc.). If LAME could provide these useful wrappers and the toolame code could be reasonably abstracted and simple, then toolame development could continue independent of LAME development and would benefit from the non-codec code in LAME. Maybe this kind of pure abstraction is just the pipe dream of a fresh CS grad who has read too many textbooks and not enough real-world code. ;) >>> It would allow easier abstraction into libraries/DLLs/whatever. I >>> like how LAME can be compiled as a Windows ACM component, too. > Anyone have windows experience that actually wants to do this? It took LAME > ages to get it done. > I'd be prepared to have a go at a *nix style library (but I don't know > anything about good API design). Awhile back I emailed with Markus Jonsson (fmj AT fmjsoft.com). He had written a dll wrapper around the tooLame executable for plugging into his software, called Awave. He said building the dll was relatively easy, but that the hard part was freeing up the memory that tooLame used (because dll's may be used several times without exiting and freeing memory.) Perhaps he would be a good resource for creating a more "proper" dll wrapper for tooLame. His dll is found here (under "Resources"): http://www.fmjsoft.com/awaveaudio.html Also, maybe we could get a couple other folks to contribute thoughts on good API design. Would Erik be interested? What about Mark Taylor or people from other Open Source audio lists? >>> Is there any way that tooLame could be >>> rolled into the LAME project > I'm going to say "I don't want to do this because it's too much work". > But, we could have a very similar API to LAME. See my notes above regarding abstracting the codec, and then using the LAME wrappers. But maybe that's unrealistic. > Having realised that tooLAME needs to evolve to be a little more useful to > everyone else, I've summarised my thinking: > > PROPOSALS for tooLAME > > tooLAME 0.2 versions > * will continue to be amazingly simple > * braindead build process of "make" and then "cp toolame <whereever>". > * no weird external library dependencies My only comment here is that with optional compile flags, external library dependencies are only dependencies if you want them to be. > * backports of anything that's related to audio quality/psymodels/etc. > tooLAME 0.4 versions > * Lets face it - i'm sick of being stuck at v0.2 and it's time to bump the > number. > * two parts: > - encoding library > - initialise layerII settings (bitrate, psymodel etc) > - takes a pointer to a sample buffer > - encodes an mpeg audio frame and writes it to file. > - or encodes and gives you back a pointer to the encoded frame > - minimal frontend > - read a simple WAV/PCM > - send it to the encoding library > - write out the encoded audio > * autotools build process > * encoding library will only encode. > - if you want resampling, you'll need a frontend that uses a libresample. > - if you want to read/write NWAAF(*) files, you'll need to use libNWAAF. Sounds great! > Hopefully you get the idea. > > This is now an official call for > * an API design > - what do other mpeg audio libraries have? > - what is LAMEs API (can we just steal it)? Can we ask Mark Taylor? > - what the hell does an ACM codec have to supply? (steve.lhomme AT free.fr) wrote the LAME ACM code and has contributed to several open source audio projects. He may be of help. Florian Bruckner (h9651030 AT miraculix.wu-wien.ac.at) did some work on ACM for Ogg Vorbis, maybe he can help too: http://www.xiph.org/archives/vorbis/200104/0317.html http://www.qdesign.com/products/about_products/acm.htm http://www.summerblue.net/computing/acm/ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/w98ddk/hh/w 98ddk/mmedia_4vjp.asp > * a link to "GNU/autotools for people who have no time". > > (* NWAAF: New Weird-Arsed-Audio Format) I'd be willing to contact some of the folks I mentioned and encourage them to contribute to the list. I'm afraid I'm not much use in the coding department. I'm continuing to play with toolame on OS X, and I'll report soon. Regards, Steve -- Steve Schultze, st...@pr... Technical Manager, The Public Radio Exchange http://www.prx.org |
From: mike <mik...@pl...> - 2003-05-27 06:02:44
|
On Tuesday 27 May 2003 09:57 am, Fred Gleason wrote: > On Monday 26 May 2003 17:56, mike wrote: > > I was trying to think what's the best way to pass in/out the sound/mp= eg. > > At the moment, I just pass in the inputfilename and the outputfilenam= e. I > > let the toolame library open them, read/write and then close. > > I don't think this is general enough. We can't assume that the data > source/end points will be files -- they could be sockets, pipes, LADSPA > plugins, JACK ports -- you name it. Yeah, that was just a statement of what it does "at the moment". Until I=20 figure out just exactly *what* i'm going to pass to the encoder. As I=20 mentioned, probably a pointer to a buffer of input audio samples, a count= of=20 the number of the samples in the buffer, and a pointer to the buffer of m= peg=20 frames returned. > > It'd be preferable to have the frontend handle the reading, as then i= t > > could read any file format it has a library for, resample it, downmix= it, > > warp it. > I don't think we'd want/need functionality like this in the front end a= t I was trying to say that *if* you wanted those things in a frontend you=20 *could* have them. I.e. disassociated the file reading from the file=20 encoding. The frontend *can* do whatever the hell it wants with the input= =20 samples, just so long as, in the end, a buffer of audio gets passed to th= e=20 encoder. > a minimal (but correct) PCM wav implementation, plus the ability to enc= ode > raw PCM data This is all I'm aiming for in the vanilla tooLame frontend. > (the quesiton of AIFF support I defer to others -- personally, I have n= o > use for it). If no one pipes up in the near future, it's gone. Any Mac users out there= who=20 can confirm/deny the use of AIFF on their platform? > You'd need to handle reblocking the data to satisfy the MPEG 1152 > sample/frame requirement.=20 So a simple frontend would do: opt =3D tooLame_createOptions() tooLame_init(opt) frontend_readaudio(inbuf, 10000) outbufBytes =3D tooLame_encode(inbuf, outbuf, 10000) //10000 samples in i= nbuf. frontend_mpeg_audio_file_write(outbuf, outbufBytes) // dumps the mpeg aud= io frontend_readaudio(inbuf, 2000) outbufBytes =3D tooLame_encode(inbuf, outbuf, 2000) frontend_mpeg_audio_file_write() outbufBytes =3D tooLame_encode_flush(outbuf); // tooLame pads, with 0s an= d makes=20 an integral number of frames. frontend_mpeg_audio_file_write() /* and probably should then do */ tooLame_deinit(opt) end That's what I think I'll try for in the next few days when I get time. If you have any comments, or feel that there's something extra to go into= the=20 interface, please pipe up... later mike |