Bugzilla – Bug 2054
Windows: Macros - "ExportMP3 before" and "ExportMP3 after" overwrite causing non-critical data loss
Last modified: 2019-01-21 07:37:15 UTC
The Manual states that: >The Export as MP3 56k before and Export as MP3 56k after commands can be used >respectively to export "before" and "after" MP3 files at 56 kbps bit rate at >any point in the Macro processing. This allows you to compare the result of >one or more effects, or provide files for different purposes with and without >a particular effect. > >* The name of the MP3 exported by the "Export as MP3 56k before" command is >prefixed by "MasterBefore " followed by the date and time. The name of the MP3 >exported by the "Export as MP3 56k after" command is prefixed by "MasterAfter_" >followed by the date and time. This is not the case when applying such a Macro to either the current project (providing it is named - either by Save or by Import) or to MP3 file(s). In these cases these commands overwrite each other's output and overwrite an MP3 export of the same input file. It is only if you have an un-named project 1) Open Audacity 2) Record 3) apply the Macro that you get anything like the documented/required behavior But that's only because Audacity then doesn't know where to store the output so you get an Export Audio dialog for that. The files do not have the "MasterBefore_" or "MasterAfter_" prefixes - just the date and time. Plus you get the oddity of the the initial MP3 file going to a "cleaned" folder on the desktop - and the before and after exports going to the folder location selected in the Export Audio dialog that was popped. This also means that running Macros on on un-named project are thus interrupted and don't operate as a true batch process as we normally intend. The overwriting of files here does cause data loss - bu non-critical - hence P2 rather than P1. =========================================== This also begs the question of why it is only for MP3s that we have before/after exports for comparison - why not the other formats too?
It would also be sensible if the before and after files also incorporated somewhere the name of the original source file - as the user may be processing many such input files at once and differentiating the would be easier with source filename incorporation.
(In reply to Peter Sampson from comment #0) > This also begs the question of why it is only for MP3s that we > have before/after exports for comparison I think this was part of the old "CleanSpeech" set of tools. > why not the other formats too? "CleanSpeech" was a set of specialist tools for a specific use case, so was limited in scope to fulfilling that use case. Personally I don't think that such specialist cases should be part of the main Audacity bundle. Much better to use optional plug-ins for specialist functionality imo.
(In reply to Steve Daulton from comment #2) I'm not seeing this bug with 2.3.1 alpha on Linux. The steps to reproduce say: [quote] 1) create or have an MP3 file on your desktop with <filename> 2)Create a Macro with "Export as MP3", "Export as MP3" 56k before" & "Export as MP3" 56k after" 3) Apply this Macro to the MP3 file 4) observe that a "cleaned" folder is created on your desktop 5) observe the the initial export in the cleaned folder is <filename>.mp3 - correct behavior 6) observe that the second export creates a (temporary) file of the form <filename>0.mp3 ] 7) observe that the third export also creates a (temporary) file of the form <filename>0.mp3 thus overwriting the one from step 6 [/quote] This is the contents of my Macro: ExportMp3: ExportMP3_56k_before: ExportMP3_56k_after: The file I imported was called "ima.mp3" A "Cleaned" folder was created on my Desktop, containing three files: * ima.mp3 * MasterAfter_ima.mp3 * MasterBefore_ima.mp3
(In reply to Steve Daulton from comment #3) Following Steve's test: 1) I repeated this on W 10 with 2.3.1 alpha - still fails 2) tested on Mac with 2.3.0 and 64-bit 2.3.1 and this works properly => So this is a Windows-only bug
Fix committed at https://github.com/audacity/audacity/commit/b3dafce Also fixes bit-rate for the ExportMP3_56k commands (not previously reported, but essentially part of the same bug (not sending correct parameters to LAME from ExportMP3_56k commands).
(In reply to Steve Daulton from comment #5) Testing on W10 with audacity-2.3.1-alpha-233-b3dafcedd1f285777484295cfdd67f59753d993c This now works correctly creating all 3 MP3 files correctly in the "cleaned" folder: <filename>.mp3, MasterAfter_<filename>.mp3, MasterBefore_<filename>.mp3 So technically this fixes this bug. But I would like also be able to test Steve's additional fix >Also fixes bit-rate for the ExportMP3_56k commands ... not sending correct >parameters to LAME from ExportMP3_56k commands but I'm unsure how to test for this.
(In reply to Peter Sampson from comment #6) > Also fixes bit-rate for the ExportMP3_56k commands Previously, the ExportMP3_56k commands would use the "last used" MP3 encoding settings, unless the last used setting were CBR (Constant Bit Rate). The default is "Preset" (VBR). The full format details, including the bit rate may be tested by uploading a file to this web page: https://mediaarea.net/MediaInfoOnline With the fix, the ExportMP3_56k commands export as 56 kbps CBR.
(In reply to Steve Daulton from comment #7) Testing this on W10 with audacity-2.3.1-alpha-233-b3dafcedd1f285777484295cfdd67f59753d993c and comparing with results on 2.3.0 I confirm that this too is fixed and works as intended
