Menu
▾
▴
sox-devel
|
From: Ryan B. <rya...@gm...> - 2008-04-12 20:25:43
|
I've been considering making python bindings for SoX with SWIG. I've used SoX a few times in short bash or python scripts so I thought it was time to make some real wrappers for it. -Has anyone attempted this before? A quick search of the mailing lists says no. -How stable will the relevant APIs be? The wrappers will be fairly high level. -Any words of wisdom or good examples anyone knows of? -Other thoughts? This is my first attempt at wrapping anything so it could get ugly! Thanks for any input, --Ryan I am not subscribed to the list so please CC me on responses. |
|
From: Chris B. <ch...@cn...> - 2008-04-13 18:15:24
|
Ryan Bair wrote: > I've been considering making python bindings for SoX with SWIG. I've > used SoX a few times in short bash or python scripts so I thought it > was time to make some real wrappers for it. > > -Has anyone attempted this before? A quick search of the mailing lists says no. > -How stable will the relevant APIs be? The wrappers will be fairly high level. > -Any words of wisdom or good examples anyone knows of? > -Other thoughts? > > This is my first attempt at wrapping anything so it could get ugly! > > Thanks for any input, > --Ryan > > I am not subscribed to the list so please CC me on responses. > I haven't heard of anyone doing python bindings before. The API for reading/writing files is probable stable at this point. Please see libsox.3 for more details. The effects API is probably the one that might change some in the future (allow runtime changing of parameters or at least restarting the effect). See the sox source package and the file src/exampl.c to see simple example of how to use the API's. Chris |
|
From: Ryan B. <rya...@gm...> - 2008-04-13 22:28:24
|
After an overview of the various Python to C interfaces out there, I'm going to go with the ctypes route. I started writing bindings today and got sox_open_read and sox_open_write working without too much difficulty. I have python classes for a decent chunk of the structs that I think I'll care about. After doing that I saw that the API changed a bit between the version of sox that came with Ubuntu Hardy ( 14.0.0 ) and cvs trunk so I have a little updating to do assuming trunk is safe to code against... I haven't touched the effects much, but that will certainly be important to me. Thanks for the heads up about that. One of the things I came across while exploring is that there currently isn't anyway to set common options ( bitrate, quality, vbr/cbr, etc ) for lossy formats, namely mp3 and vorbis. Are there any plans in the works for such options? --Ryan On Sun, Apr 13, 2008 at 2:06 PM, Chris Bagwell <ch...@cn...> wrote: > > Ryan Bair wrote: > > > I've been considering making python bindings for SoX with SWIG. I've > > used SoX a few times in short bash or python scripts so I thought it > > was time to make some real wrappers for it. > > > > -Has anyone attempted this before? A quick search of the mailing lists > says no. > > -How stable will the relevant APIs be? The wrappers will be fairly high > level. > > -Any words of wisdom or good examples anyone knows of? > > -Other thoughts? > > > > This is my first attempt at wrapping anything so it could get ugly! > > > > Thanks for any input, > > --Ryan > > > > I am not subscribed to the list so please CC me on responses. > > > > > I haven't heard of anyone doing python bindings before. > The API for reading/writing files is probable stable at this point. Please > see libsox.3 for more details. > > The effects API is probably the one that might change some in the future > (allow runtime changing of parameters or at least restarting the effect). > > See the sox source package and the file src/exampl.c to see simple example > of how to use the API's. > > Chris > |
|
From: robs <aq...@ya...> - 2008-04-14 07:05:35
|
--- Ryan Bair <rya...@gm...> wrote:
> I have a little updating to do assuming trunk is safe to code
> against...
I'm pretty happy with the trunk changes and don't have much in the pipeline on
changing the file or the effects API, so I think you're safe for the time
being.
I'm afraid that the libsox man page is woefully out of date, so your main
points of reference will be example[12].c and sox.h (& last, 'cos it's
complicated, sox.c).
I suspect that the mission you are undertaking will bring out a few
peccadilloes (or at least areas of lack of clarity) in the API so please raise
questions and improvement suggestions.
> One of the things I came across while exploring is that there
> currently isn't anyway to set common options ( bitrate, quality,
> vbr/cbr, etc ) for lossy formats, namely mp3 and vorbis. Are there any
> plans in the works for such options?
There's a crude (but so far adequate) mechanism: sox_encodinginfo_t has a
`compression' value, currently used by vorbis & FLAC---patches to extend this
for mp3 (lame) are welcome.
Cheers,
Rob
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
|
|
From: robs <aq...@ya...> - 2008-04-14 07:07:38
|
Chris, I've been thinking of late that the best way to get (and keep) libSoX
documentation up to date is to abandon (or cut down to a pointer) the man page
and doxygen-ise sox.h; it's what a lot of lib projects do these days---what do
you think?
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
|
|
From: Chris B. <ch...@cn...> - 2008-04-14 13:19:37
|
robs wrote: > Chris, I've been thinking of late that the best way to get (and keep) libSoX > documentation up to date is to abandon (or cut down to a pointer) the man page > and doxygen-ise sox.h; it's what a lot of lib projects do these days---what do > you think? > Yes, I'm in that club of people that think its better to document the code inside the code itself. So I'm fine with that. I guess there is some debate on if description text should be inside *.c code or sox.h. Its better to me in sox.h because users of the library have the docs right there inline. But it bloats that file pretty good and its not as handy to update the descriptions if you change the behavior in *.c. Chris |
|
From: Ryan B. <rya...@gm...> - 2008-04-14 12:36:15
|
Being able to set MP3 bitrates is extremely important to me, so I will probably (try to) add it. My C skills are lacking so feel free to pick any patches apart that I may send. Once my bindings are in a semi-usable condition, that will probably be next up on my plate. --Ryan On Mon, Apr 14, 2008 at 3:05 AM, robs <aq...@ya...> wrote: > --- Ryan Bair <rya...@gm...> wrote: > > I have a little updating to do assuming trunk is safe to code > > against... > > I'm pretty happy with the trunk changes and don't have much in the pipeline on > changing the file or the effects API, so I think you're safe for the time > being. > > I'm afraid that the libsox man page is woefully out of date, so your main > points of reference will be example[12].c and sox.h (& last, 'cos it's > complicated, sox.c). > > I suspect that the mission you are undertaking will bring out a few > peccadilloes (or at least areas of lack of clarity) in the API so please raise > questions and improvement suggestions. > > > > One of the things I came across while exploring is that there > > currently isn't anyway to set common options ( bitrate, quality, > > vbr/cbr, etc ) for lossy formats, namely mp3 and vorbis. Are there any > > plans in the works for such options? > > There's a crude (but so far adequate) mechanism: sox_encodinginfo_t has a > `compression' value, currently used by vorbis & FLAC---patches to extend this > for mp3 (lame) are welcome. > > Cheers, > Rob > > > > ___________________________________________________________ > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
|
From: Ryan B. <rya...@gm...> - 2008-04-14 21:03:55
|
I'm having a bit of difficulty figuring out the effects. For my quick look over things SoX's current behavior is very roughly something like this: - We parse the effects arguments and insert them into user_efftab array. - We make an effects chain - We call add_effects on the chain which then adds the input effect, effects from efftab, and then the output effect. Input effect comes from input_combiner_effect_fn which makes a handler using the combiner_* functions. - sox_flow_effects until we're done. So far I have: -sox_create_effects_chain -Do something to add input... -Call add_effect for each of my effects -Do something to add output... I'm not so sure how to implement the input and output. Example 1 has effects and it seems like it has its own input and output handlers with drain and flow implemented respectively. I'd really like to avoid that for something that is so routine. If there's nothing else out there, would it make sense to move the input_combiner_effect_fn and output_effect_fn's out into effects.c? They seem like they should fit the bill for most purposes unless I'm looking at this wrong. --Ryan --Ryan On Mon, Apr 14, 2008 at 8:36 AM, Ryan Bair <rya...@gm...> wrote: > Being able to set MP3 bitrates is extremely important to me, so I will > probably (try to) add it. My C skills are lacking so feel free to pick > any patches apart that I may send. Once my bindings are in a > semi-usable condition, that will probably be next up on my plate. > > --Ryan > > > > On Mon, Apr 14, 2008 at 3:05 AM, robs <aq...@ya...> wrote: > > --- Ryan Bair <rya...@gm...> wrote: > > > I have a little updating to do assuming trunk is safe to code > > > against... > > > > I'm pretty happy with the trunk changes and don't have much in the pipeline on > > changing the file or the effects API, so I think you're safe for the time > > being. > > > > I'm afraid that the libsox man page is woefully out of date, so your main > > points of reference will be example[12].c and sox.h (& last, 'cos it's > > complicated, sox.c). > > > > I suspect that the mission you are undertaking will bring out a few > > peccadilloes (or at least areas of lack of clarity) in the API so please raise > > questions and improvement suggestions. > > > > > > > One of the things I came across while exploring is that there > > > currently isn't anyway to set common options ( bitrate, quality, > > > vbr/cbr, etc ) for lossy formats, namely mp3 and vorbis. Are there any > > > plans in the works for such options? > > > > There's a crude (but so far adequate) mechanism: sox_encodinginfo_t has a > > `compression' value, currently used by vorbis & FLAC---patches to extend this > > for mp3 (lame) are welcome. > > > > Cheers, > > Rob > > > > > > > > ___________________________________________________________ > > Yahoo! For Good helps you make a difference > > > > http://uk.promotions.yahoo.com/forgood/ > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > SoX-devel mailing list > > SoX...@li... > > https://lists.sourceforge.net/lists/listinfo/sox-devel > > > |
|
From: robs <aq...@ya...> - 2008-04-15 18:05:49
|
--- Ryan Bair <rya...@gm...> wrote:
> I'm having a bit of difficulty figuring out the effects. For my quick
> look over things SoX's current behavior is very roughly something like
> this:
>
> - We parse the effects arguments and insert them into user_efftab array.
This is done in sox.c, but it's not strictly necessary.
> - We make an effects chain
> - We call add_effects on the chain which then adds the input effect,
> effects from efftab, and then the output effect. Input effect comes
> from input_combiner_effect_fn which makes a handler using the
> combiner_* functions.
Again, the combiner is only used in sox.c.
> If there's nothing else out there, would it make sense to move the
> input_combiner_effect_fn and output_effect_fn's out into effects.c?
> They seem like they should fit the bill for most purposes unless I'm
> looking at this wrong.
Yes it would make sense to put them into libSoX (though of course, there may be
apps that already have audio IO in place and just want to use some SoX effects,
so custom IO handlers will still be needed). It's been something I've had on
the to-do list for a while, but separating them from sox.c specific stuff and
getting the API right will take a bit of thought and time, and I'm afraid I'm
busy hacking in other areas at the moment.
Cheers,
Rob
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
|
|
From: Ryan B. <rya...@gm...> - 2008-04-15 21:43:54
|
So to create an input effect, can I just use sox_read as the drain? For the output effect can I just set sox_write as the flow? Or do I need to write my own generic drain and flow functions. After this I think I'm home free and my SimpleSox class should start doing useful things :-). Thanks --Ryan On Tue, Apr 15, 2008 at 2:05 PM, robs <aq...@ya...> wrote: > --- Ryan Bair <rya...@gm...> wrote: > > > > I'm having a bit of difficulty figuring out the effects. For my quick > > look over things SoX's current behavior is very roughly something like > > this: > > > > - We parse the effects arguments and insert them into user_efftab array. > > This is done in sox.c, but it's not strictly necessary. > > > > - We make an effects chain > > - We call add_effects on the chain which then adds the input effect, > > effects from efftab, and then the output effect. Input effect comes > > from input_combiner_effect_fn which makes a handler using the > > combiner_* functions. > > Again, the combiner is only used in sox.c. > > > > If there's nothing else out there, would it make sense to move the > > input_combiner_effect_fn and output_effect_fn's out into effects.c? > > They seem like they should fit the bill for most purposes unless I'm > > looking at this wrong. > > Yes it would make sense to put them into libSoX (though of course, there may be > apps that already have audio IO in place and just want to use some SoX effects, > so custom IO handlers will still be needed). It's been something I've had on > the to-do list for a while, but separating them from sox.c specific stuff and > getting the API right will take a bit of thought and time, and I'm afraid I'm > busy hacking in other areas at the moment. > > > > Cheers, > Rob > > > ___________________________________________________________ > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
|
From: Ryan B. <rya...@gm...> - 2008-04-16 02:04:10
|
Last reply to myself... The biggest thing that I am stuck on is that right now the input and output sox_format_t structs are global and really need to be. Unless I'm reading this wrong, theres no way to get sox_format_t into the sox_effects_handler pointer functions except by global definition. Is there _any_ way around this? I won't be able to accomplish my goals if I can't operate multiple effects chains simultaneously. --Ryan On Tue, Apr 15, 2008 at 5:43 PM, Ryan Bair <rya...@gm...> wrote: > So to create an input effect, can I just use sox_read as the drain? > For the output effect can I just set sox_write as the flow? Or do I > need to write my own generic drain and flow functions. > > After this I think I'm home free and my SimpleSox class should start > doing useful things :-). > > Thanks > --Ryan > > > > On Tue, Apr 15, 2008 at 2:05 PM, robs <aq...@ya...> wrote: > > --- Ryan Bair <rya...@gm...> wrote: > > > > > > > I'm having a bit of difficulty figuring out the effects. For my quick > > > look over things SoX's current behavior is very roughly something like > > > this: > > > > > > - We parse the effects arguments and insert them into user_efftab array. > > > > This is done in sox.c, but it's not strictly necessary. > > > > > > > - We make an effects chain > > > - We call add_effects on the chain which then adds the input effect, > > > effects from efftab, and then the output effect. Input effect comes > > > from input_combiner_effect_fn which makes a handler using the > > > combiner_* functions. > > > > Again, the combiner is only used in sox.c. > > > > > > > If there's nothing else out there, would it make sense to move the > > > input_combiner_effect_fn and output_effect_fn's out into effects.c? > > > They seem like they should fit the bill for most purposes unless I'm > > > looking at this wrong. > > > > Yes it would make sense to put them into libSoX (though of course, there may be > > apps that already have audio IO in place and just want to use some SoX effects, > > so custom IO handlers will still be needed). It's been something I've had on > > the to-do list for a while, but separating them from sox.c specific stuff and > > getting the API right will take a bit of thought and time, and I'm afraid I'm > > busy hacking in other areas at the moment. > > > > > > > > Cheers, > > Rob > > > > > > ___________________________________________________________ > > Yahoo! For Good helps you make a difference > > > > http://uk.promotions.yahoo.com/forgood/ > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > SoX-devel mailing list > > SoX...@li... > > https://lists.sourceforge.net/lists/listinfo/sox-devel > > > |
|
From: robs <aq...@ya...> - 2008-04-16 07:23:10
Attachments:
example1.c
|
--- Ryan Bair <rya...@gm...> wrote:
> I'm reading this wrong, theres no way to get sox_format_t into the
> sox_effects_handler pointer functions except by global definition. Is
> there _any_ way around this? I won't be able to accomplish my goals if
> I can't operate multiple effects chains simultaneously.
Please do a CVS update, have a look at the new example0.c, and let me know what
you think.
Cheers,
Rob
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/ |
|
From: Ryan B. <rya...@gm...> - 2008-04-16 13:15:08
|
Awesome! I was looking at this some more last night and determined that I could put my file in priv_t struct and then write drain to use the handle from there. I was quite pleasantly surprised when I ran cvs up this morning and the files I was about to write were already there. Thanks, Rob! --Ryan On Wed, Apr 16, 2008 at 3:23 AM, robs <aq...@ya...> wrote: > --- Ryan Bair <rya...@gm...> wrote: > > > I'm reading this wrong, theres no way to get sox_format_t into the > > sox_effects_handler pointer functions except by global definition. Is > > there _any_ way around this? I won't be able to accomplish my goals if > > I can't operate multiple effects chains simultaneously. > > Please do a CVS update, have a look at the new example0.c, and let me know what > you think. > > > > Cheers, > Rob > > > ___________________________________________________________ > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > > |
|
From: robs <aq...@ya...> - 2008-04-16 18:07:12
|
--- Ryan Bair <rya...@gm...> wrote:
> Awesome! I was looking at this some more last night and determined
> that I could put my file in priv_t struct and then write drain to use
> the handle from there. I was quite pleasantly surprised when I ran cvs
> up this morning and the files I was about to write were already there.
Turned out it was quite easy to get thus far. Extricating the combiner could be
trickier, but it sounds like you've you got enough to keep you going for now.
Cheers,
Rob
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
|
|
From: Ryan B. <rya...@gm...> - 2008-04-16 21:02:57
|
I was able to feed a 44100Hz wave file in and get a 48000Hz aiff file out, fantastic. I need to do a bit of cleanup work and I'm looking to setup some common functions as class methods where it makes sense. The effects chain will pick up add_effect and flow_effects for instance. All in all its going OK. My next adventure is mp3 bitrates. Getting the code in mp3.c should be pretty straight forward but I need to get the information in into the struct first. Right now in sox_encodinginfo_t we have bits_per_sample ( not applicable to MP3s ) and compression ( useful for VBR ). I'm needing some CBR action so I need to pass bitrate into there somehow. I could either hijack one of previously mentioned variables ( bits_per_sample because it doesn't make sense to this format or compression because the highest quality number, 10, is below the lowest valid bitrate, 32 ) or the better method would probably be to add bitrate to the sox_encoding_t struct. Thoughts? --Ryan On Wed, Apr 16, 2008 at 2:07 PM, robs <aq...@ya...> wrote: > --- Ryan Bair <rya...@gm...> wrote: > > > > Awesome! I was looking at this some more last night and determined > > that I could put my file in priv_t struct and then write drain to use > > the handle from there. I was quite pleasantly surprised when I ran cvs > > up this morning and the files I was about to write were already there. > > Turned out it was quite easy to get thus far. Extricating the combiner could be > trickier, but it sounds like you've you got enough to keep you going for now. > > > > Cheers, > Rob > > > ___________________________________________________________ > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
|
From: Chris B. <ch...@cn...> - 2008-04-16 21:53:58
|
My preference is to use the "compression" variable so that this allow works with SoX -compression option. We don't have a command line option for bits_per_sample other then -1, -2, -4, and -8. Here are my preferences, in order, on how to treat compression value in mp3.c. Rob, if you have a preference then please let us know. 1) I'd look at lame's usage of their --compression flag and emulate that if possible. That sounds exactly like how vorbis and flac handlers are treating the command line option. I think lame uses a float so you'd have to do something like treat 110 in SoX to mean 11.0 on lame's command line. 2) Treat compression to mean a specific bitrate while in mp3 handler. Would need to check that its a valid bitrate. 3) Remap the compression value using a fixed mapping from 1-14 to lame's 14 values for -b option. Document somewhere that 1=8, 2=16, etc. Once we need to go beyond bitrate (such as setting VBR vs. CBR) then I think we need to add a new field to sox_encoding_info_t thats just a string. Then allow user to pass in a string thats unique to that file handler and have it parse the string. I'm borrowing these ideas from programs like mencoder... We could do something like: sox infile.wav --codec-options="vbr:mode=join" --compression=11 outfile.mp3 and this way we won't have to worry about finding generic ways of handling all codec concepts. Chris Ryan Bair wrote: > I was able to feed a 44100Hz wave file in and get a 48000Hz aiff file > out, fantastic. I need to do a bit of cleanup work and I'm looking to > setup some common functions as class methods where it makes sense. The > effects chain will pick up add_effect and flow_effects for instance. > All in all its going OK. > > My next adventure is mp3 bitrates. Getting the code in mp3.c should be > pretty straight forward but I need to get the information in into the > struct first. Right now in sox_encodinginfo_t we have bits_per_sample > ( not applicable to MP3s ) and compression ( useful for VBR ). I'm > needing some CBR action so I need to pass bitrate into there somehow. > I could either hijack one of previously mentioned variables ( > bits_per_sample because it doesn't make sense to this format or > compression because the highest quality number, 10, is below the > lowest valid bitrate, 32 ) or the better method would probably be to > add bitrate to the sox_encoding_t struct. > > Thoughts? > > --Ryan > > On Wed, Apr 16, 2008 at 2:07 PM, robs <aq...@ya...> wrote: > >> --- Ryan Bair <rya...@gm...> wrote: >> >> >> >>> Awesome! I was looking at this some more last night and determined >>> >> > that I could put my file in priv_t struct and then write drain to use >> > the handle from there. I was quite pleasantly surprised when I ran cvs >> > up this morning and the files I was about to write were already there. >> >> Turned out it was quite easy to get thus far. Extricating the combiner could be >> trickier, but it sounds like you've you got enough to keep you going for now. >> >> >> >> Cheers, >> Rob >> >> >> ___________________________________________________________ >> Yahoo! For Good helps you make a difference >> >> http://uk.promotions.yahoo.com/forgood/ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> SoX-devel mailing list >> SoX...@li... >> https://lists.sourceforge.net/lists/listinfo/sox-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
|
From: robs <aq...@ya...> - 2008-04-16 22:37:19
|
Don't know much about lame so not much to add really. sox_encoding_info_t.compression is a double so you've got 50-odd bits to play with if you want to do something quick and dirty, e.g. 128.10 to represent 2 numbers 128 and 10, but I think the codec-options idea is probably the way to go in the longer run. /Rob --- Chris Bagwell <ch...@cn...> wrote: > My preference is to use the "compression" variable so that this allow > works with SoX -compression option. We don't have a command line option > for bits_per_sample other then -1, -2, -4, and -8. > > Here are my preferences, in order, on how to treat compression value in > mp3.c. Rob, if you have a preference then please let us know. > > 1) I'd look at lame's usage of their --compression flag and emulate that > if possible. That sounds exactly like how vorbis and flac handlers are > treating the command line option. I think lame uses a float so you'd > have to do something like treat 110 in SoX to mean 11.0 on lame's > command line. > > 2) Treat compression to mean a specific bitrate while in mp3 handler. > Would need to check that its a valid bitrate. > > 3) Remap the compression value using a fixed mapping from 1-14 to lame's > 14 values for -b option. Document somewhere that 1=8, 2=16, etc. > > Once we need to go beyond bitrate (such as setting VBR vs. CBR) then I > think we need to add a new field to sox_encoding_info_t thats just a > string. Then allow user to pass in a string thats unique to that file > handler and have it parse the string. I'm borrowing these ideas from > programs like mencoder... We could do something like: > > sox infile.wav --codec-options="vbr:mode=join" --compression=11 outfile.mp3 > > and this way we won't have to worry about finding generic ways of > handling all codec concepts. > > Chris > > Ryan Bair wrote: > > I was able to feed a 44100Hz wave file in and get a 48000Hz aiff file > > out, fantastic. I need to do a bit of cleanup work and I'm looking to > > setup some common functions as class methods where it makes sense. The > > effects chain will pick up add_effect and flow_effects for instance. > > All in all its going OK. > > > > My next adventure is mp3 bitrates. Getting the code in mp3.c should be > > pretty straight forward but I need to get the information in into the > > struct first. Right now in sox_encodinginfo_t we have bits_per_sample > > ( not applicable to MP3s ) and compression ( useful for VBR ). I'm > > needing some CBR action so I need to pass bitrate into there somehow. > > I could either hijack one of previously mentioned variables ( > > bits_per_sample because it doesn't make sense to this format or > > compression because the highest quality number, 10, is below the > > lowest valid bitrate, 32 ) or the better method would probably be to > > add bitrate to the sox_encoding_t struct. > > > > Thoughts? > > > > --Ryan > > > > On Wed, Apr 16, 2008 at 2:07 PM, robs <aq...@ya...> wrote: > > > >> --- Ryan Bair <rya...@gm...> wrote: > >> > >> > >> > >>> Awesome! I was looking at this some more last night and determined > >>> > >> > that I could put my file in priv_t struct and then write drain to use > >> > the handle from there. I was quite pleasantly surprised when I ran cvs > >> > up this morning and the files I was about to write were already there. > >> > >> Turned out it was quite easy to get thus far. Extricating the combiner > could be > >> trickier, but it sounds like you've you got enough to keep you going for > now. > >> > >> > >> > >> Cheers, > >> Rob > >> > >> > >> ___________________________________________________________ > >> Yahoo! For Good helps you make a difference > >> > >> http://uk.promotions.yahoo.com/forgood/ > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >> Don't miss this year's exciting event. There's still time to save $100. > >> Use priority code J8TL2D2. > >> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >> _______________________________________________ > >> SoX-devel mailing list > >> SoX...@li... > >> https://lists.sourceforge.net/lists/listinfo/sox-devel > >> > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > SoX-devel mailing list > > SoX...@li... > > https://lists.sourceforge.net/lists/listinfo/sox-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ |
|
From: Ryan B. <rya...@gm...> - 2008-04-17 16:07:14
|
I joined in. I figured I'll be hanging around for a while so its probably the thing to do. LAME has three modes of operation, CBR (constant), ABR (average), and VBR(variable) in terms of ascending quality. We can have sample rates of 32, 44.1 and 48 kHz and bitrates of 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, 192, 224, 256 and 320 kbit/s for CBR. ABR can take any number between 8 and 310 to use as the average bitrate. VBR takes a VBR quality number between 0 and 9. Then there are also encoding quality levels of 0-9, I would default at 2 as it seems to be the best time/quality trade-off IMO. I'm trying to sway people over to VBR at the moment so maybe this won't be an issue and I'll just use compression as the VBR number. I'm adding in the code for using ft->encoding.compression as the VBR quality level now. It should be pretty straight forward... I agree that a codec options would be the way to go for long term. Looking over vorbis.c. I see that we have a default quality of 3, then we check if we have a valid value in ft->encoding.compression value and set quality equal to that. But it doesn't seem like it is ever used. --Ryan On Wed, Apr 16, 2008 at 6:37 PM, robs <aq...@ya...> wrote: > Don't know much about lame so not much to add really. > sox_encoding_info_t.compression is a double so you've got 50-odd bits to play > with if you want to do something quick and dirty, e.g. 128.10 to represent 2 > numbers 128 and 10, but I think the codec-options idea is probably the way to > go in the longer run. > > /Rob > > > > > --- Chris Bagwell <ch...@cn...> wrote: > > > My preference is to use the "compression" variable so that this allow > > works with SoX -compression option. We don't have a command line option > > for bits_per_sample other then -1, -2, -4, and -8. > > > > Here are my preferences, in order, on how to treat compression value in > > mp3.c. Rob, if you have a preference then please let us know. > > > > 1) I'd look at lame's usage of their --compression flag and emulate that > > if possible. That sounds exactly like how vorbis and flac handlers are > > treating the command line option. I think lame uses a float so you'd > > have to do something like treat 110 in SoX to mean 11.0 on lame's > > command line. > > > > 2) Treat compression to mean a specific bitrate while in mp3 handler. > > Would need to check that its a valid bitrate. > > > > 3) Remap the compression value using a fixed mapping from 1-14 to lame's > > 14 values for -b option. Document somewhere that 1=8, 2=16, etc. > > > > Once we need to go beyond bitrate (such as setting VBR vs. CBR) then I > > think we need to add a new field to sox_encoding_info_t thats just a > > string. Then allow user to pass in a string thats unique to that file > > handler and have it parse the string. I'm borrowing these ideas from > > programs like mencoder... We could do something like: > > > > sox infile.wav --codec-options="vbr:mode=join" --compression=11 outfile.mp3 > > > > and this way we won't have to worry about finding generic ways of > > handling all codec concepts. > > > > Chris > > > > Ryan Bair wrote: > > > I was able to feed a 44100Hz wave file in and get a 48000Hz aiff file > > > out, fantastic. I need to do a bit of cleanup work and I'm looking to > > > setup some common functions as class methods where it makes sense. The > > > effects chain will pick up add_effect and flow_effects for instance. > > > All in all its going OK. > > > > > > My next adventure is mp3 bitrates. Getting the code in mp3.c should be > > > pretty straight forward but I need to get the information in into the > > > struct first. Right now in sox_encodinginfo_t we have bits_per_sample > > > ( not applicable to MP3s ) and compression ( useful for VBR ). I'm > > > needing some CBR action so I need to pass bitrate into there somehow. > > > I could either hijack one of previously mentioned variables ( > > > bits_per_sample because it doesn't make sense to this format or > > > compression because the highest quality number, 10, is below the > > > lowest valid bitrate, 32 ) or the better method would probably be to > > > add bitrate to the sox_encoding_t struct. > > > > > > Thoughts? > > > > > > --Ryan > > > > > > On Wed, Apr 16, 2008 at 2:07 PM, robs <aq...@ya...> wrote: > > > > > >> --- Ryan Bair <rya...@gm...> wrote: > > >> > > >> > > >> > > >>> Awesome! I was looking at this some more last night and determined > > >>> > > >> > that I could put my file in priv_t struct and then write drain to use > > >> > the handle from there. I was quite pleasantly surprised when I ran cvs > > >> > up this morning and the files I was about to write were already there. > > >> > > >> Turned out it was quite easy to get thus far. Extricating the combiner > > could be > > >> trickier, but it sounds like you've you got enough to keep you going for > > now. > > >> > > >> > > >> > > >> Cheers, > > >> Rob > > >> > > >> > > >> ___________________________________________________________ > > >> Yahoo! For Good helps you make a difference > > >> > > >> http://uk.promotions.yahoo.com/forgood/ > > >> > > >> ------------------------------------------------------------------------- > > >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > >> Don't miss this year's exciting event. There's still time to save $100. > > >> Use priority code J8TL2D2. > > >> > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > >> _______________________________________________ > > >> SoX-devel mailing list > > >> SoX...@li... > > >> https://lists.sourceforge.net/lists/listinfo/sox-devel > > >> > > >> > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > > Don't miss this year's exciting event. There's still time to save $100. > > > Use priority code J8TL2D2. > > > > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > > _______________________________________________ > > > SoX-devel mailing list > > > SoX...@li... > > > https://lists.sourceforge.net/lists/listinfo/sox-devel > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > SoX-devel mailing list > > SoX...@li... > > https://lists.sourceforge.net/lists/listinfo/sox-devel > > > > > > ___________________________________________________________ > > > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
|
From: Chris B. <ch...@cn...> - 2008-04-17 17:11:56
|
On Thu, Apr 17, 2008 at 12:07:04PM -0400, Ryan Bair wrote: > Looking over vorbis.c. I see that we have a default quality of 3, then > we check if we have a valid value in ft->encoding.compression value > and set quality equal to that. But it doesn't seem like it is ever > used. > That threw me at first as well. Right beneath it, it includes vorbis1.h which is C code and it references it. Dunno the history behind that magic. Chris |
|
From: robs <aq...@ya...> - 2008-04-17 18:19:52
|
--- Chris Bagwell <ch...@cn...> wrote:
> On Thu, Apr 17, 2008 at 12:07:04PM -0400, Ryan Bair wrote:
> > Looking over vorbis.c. I see that we have a default quality of 3, then
> > we check if we have a valid value in ft->encoding.compression value
> > and set quality equal to that. But it doesn't seem like it is ever
> > used.
> >
>
> That threw me at first as well. Right beneath it, it includes
> vorbis1.h which is C code and it references it.
>
> Dunno the history behind that magic.
Apologies for the lack of clarity introduced by these (there are a few in
total) little header files with c code. In an attempt to maintain the quality
of the code base, I now build locally with -Werror. This, of course, requires
zero warnings produced in the entire build. I fixed almost all the warnings
but there were a few I couldn't get rid of any other way---unfortunately, gcc
requires the disable-warning pragma (`GCC system_header') to be in a header
file.
/Rob
___________________________________________________________
Yahoo! For Good helps you make a difference
http://uk.promotions.yahoo.com/forgood/
|
|
From: Chris B. <ch...@cn...> - 2008-04-17 18:30:52
|
On Thu, Apr 17, 2008 at 07:19:34PM +0100, robs wrote: > unfortunately, gcc > requires the disable-warning pragma (`GCC system_header') to be in a header > file. Interesting, since I rarely use pragma's I wasn't aware of that gcc restriction. Good to know. |
|
From: Ryan B. <rya...@gm...> - 2008-04-17 20:58:31
|
I got VBR working today and I'm using the compression value as the VBR quality level. All of the changes were in mp3.c except for one in sox_open_write where I changed the mode from wb to wb+ as required by LAME for writing the VBR tags. Initial results look promising after I figured out that you need to make a call to manually write the VBR tag even after calling lame_set_bWriteVbrTag on versions less than 3.98. I'm going to run it through a big batch of wave files and I'll send up patches tomorrow if it looks good. On Thu, Apr 17, 2008 at 2:30 PM, Chris Bagwell <ch...@cn...> wrote: > On Thu, Apr 17, 2008 at 07:19:34PM +0100, robs wrote: > > unfortunately, gcc > > requires the disable-warning pragma (`GCC system_header') to be in a header > > file. > > Interesting, since I rarely use pragma's I wasn't aware of that gcc > restriction. Good to know. > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
Thanks for helping keep SourceForge clean.
X