Thank you for the detailed anomaly report !
I will work on those points as soon as possible, but probably not before next Sunday...
> Date: Tue, 30 Jul 2013 02:15:19 +0100
> From: gale@...
> To: audacity-devel@...
> Subject: Re: [Audacity-devel] Several "Export" commands for batch chains patch
> | From Joel Bouchat <bouchat@...>
> | Tue, 23 Jul 2013 17:37:46 +0200
> | Subject: [Audacity-devel] Several "Export" commands for batch chains patch
>> Here is the updated patch following the remarks received from Gale.
> Thanks for your efforts, Joel. Sorry I have not been able to test
> it until now.
> First off, a bug has got in there at some stage. Some of the
> effects open the Chain export dialogues e.g.
> * Normalize opens Export GSM
> * Noise Removal opens Export FLAC
> * Repeat opens Export WAV
> and some items open the wrong effects (Truncate Silence does
> MP2/MP3 and the greying out of OK seem to have problems, as
> detailed below.
>> * Selecting "unchanged" in the sample rate drop-down in the
>> parameters dialogs then choosing OK resets itself to the
>> lowest sample rate in the list (and that rate is actually used).
>> ==> Fixed. Last time, i added a check on the samplerate range and i
>> forgot that "0" is a valid sampling value, it means "unchanged". "The
>> best is the enemy of the good" !
> OK, thanks.
>> * "ExportWMA" saves files with WMV extension.
>> ==> Modified to "wma".
> OK, that works now.
>> Also modified in the original "ExportFFmpeg.cpp" code: the "file selector" was "asf","wmv"...
>> I have replaced "wmv" with "wma".
> OK, it's fair enough to warn if you try to export as WMV, thanks.
>> * Don't we want an "ExportMP2" command?
>> ==> Done.
> Something is not quite correct for this one.
> 48000 Hz 56 kbps MP2 is valid, and works if you select the sample
> rate explicitly in the dialogue.
> But if you choose "unchanged" with a project rate of 48000 Hz,
> 56 kbps export fails with "cannot export with this sample rate and
> bit rate".
>> * Do we want an "ExportGSM 6.10WAV" command? Perhaps not, but
>> using "ExportPCM" in a Chain to export GSM fails on a stereo track
>> "cannot export audio". The same issue occurs if you use "Other
>> uncompressed files" straight export to GSM (but not if you choose
>> the "GSM 6.10 WAV (mobile)" straight export item).
>> ==> Done. Forced to "Mono" mode, as for the "AMR" exportation.
>> I have added the sampling frequency selector to the "parameters".
>> Setting the sampling rate is the only way to modify the encoded result
>> (size & quality).
> Thanks. Should the rates in the dialogue go up to 384000 since
> those are valid (notwithstanding any quality issues)?
> Do you think you could also force to mono when exporting to GSM
> via Export PCM (Chain) and "Other uncompressed files" (straight
>> * I like the automatic change of sample rate where sample rate is
>> incompatible with bit rate (e.g. MP3 8000 Hz 256 kbps is changed
>> to 32000 Hz sample rate) - as long as that's documented.
>> But should the Chain store the modified sample rate so user can
>> see what rate is actually used?
>> ==> The ExportMP3 command, and the newly implemented ExportMP2
>> command, now include a check in the dialog box that inhibits the "OK"
>> button when the sample frequency don't fit the bit rate.
> Does anyone have views if we should show brief explanatory text
> when the OK button is greyed? See Truncate Silence for an example.
> I think it may be a good idea, because the problem may not be
> obvious if sample rate is "unchanged" but the project rate is too
> There seem to be two problems with MP3 export:
> * Some valid CBR sample rate/bit rate combinations e.g. 48000 Hz /
> 56 kbps cause OK to grey out, either if chosen explicitly or if you
> choose "unchanged" with project rate on 48000 Hz. But if you
> change to VBR, OK ungreys.
> * Some combinations don't export the indicated bit rate e.g.
> 8000 Hz / 128 kbps CBR when exporting from a mono or stereo
> track produces a 64 kbps file.
> Also for FFmpeg formats (I tested WMA and AC3), if you choose
> "unchanged" and the project rate is too high, no greying out or
> silent correction occurs. So if the project rate is e.g. 384000 Hz
> the Chain produces a zero bytes file.
>> Also, the sample frequency is displayed in the "progress" message when
>> the chain is executed.
> I see sample rate and bit rate are included in the progress dialogue
> for straight MP3/MP2 export too. That's OK by me.
> If it's OK by others, should we do the same for:
> * for all compressed formats where there may be sample
> rate/bit rate conflicts
> * all compressed formats that use bit rate
> * or for all compressed formats (including those that have a quality
> rather than bit rate parameter)?
> I'm OK with doing it for all compressed formats.
>> Remark: The most awkward situation is when the bitrate is 144 kbps :
>> the sample rate must be <= 24000 sps ! Cannot understand why! Is it a
>> limitation of the lame encoder or is it specified in the mp3 standard?
> I agree it's odd given that 128 kbps @ 44100 Hz is accepted, but that
> is the standard:
> http://wiki.audacityteam.org/wiki/Lame_Installation#valid .
>> * Why do the ExportMP3 bit rate settings differ from those in
>> Straight export (no Presets, changed text in the drop-down,
>> defaults to 256 kbps stereo instead of 128 kbps JS)?
>> IIRC Steve wants to make the MP3 export default 256 kbps
>> stereo. I feel that might create "too large" files for many, but
>> either way shouldn't the defaults for Chains match with those
>> for straight export? Similarly you seem to have increased
>> default WMA bit rate and AAC quality.
>> ==> Ok, i have cancelled the discrepancies. Here are the default values used:
>> mp3: constant 128k Joint Stereo
>> ogg: quality 5
>> flac: level 5 16 bits
>> mp2 160 kbps
>> AAC quality 100
>> AC3 160 kbps
>> AMR 12.2 kbps
>> WMA 96 kbps
>> WAV 16 bits
>> AIFF 16 bits
>> BUT, i totally agree with Steve, 128 kbps belongs to the past, when mp3
>> players had 128 M.O. of Flash memory!
>> The present trend is to use 320 KBPS or 256KBPS VBR, (Amazon, Sony Music, ...).
>> Listening to music encoded at 128kbps is some kind of masochism, especially
>> in Joint Stereo with a headphone!
> I guess I could ask for votes on the -quality list if we want to review
> this. There are concerns for huge files like audio books, and people
> uploading to web sites.
>> * I tested what happened if user came from previous Audacity to
>> your patched version where they had an existing ExportWAV
>> Chain command.
>> It doesn't seem a problem, except that if they are working with
>> other than 44100 Hz sample rate, they will get 44100 Hz export
>> in your version instead of the rate they were expecting (and they
>> won't see that until they press the "Edit Parameters" button).
>> Should anything be done e.g. if the text file for the Chain has no
>> parameters, export as "unchanged" rate and store that?
>> ==> Done. A very simple solution using a flag in the project class.
>> This flag states that the command holds no parameter.
>> Now, when no parameters are present, the chain Export commands
>> use the parameters of the last straight Export performed, or the default
>> values. The sampling rate is the value saved in the preferences.
> Thanks. If there are no parameters in the ExportWAV chain, the
> chain export seems to use the current project rate (as switched to
> by file import when appropriate). So I think that's fine.
> Thanks again for your efforts.
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> audacity-devel mailing list