View Issue Details
|ID||Category||Date Submitted||Last Update|
|0006412||bugs||2015-07-04 12:04||2020-04-19 20:17|
|Fixed in Version|
|Summary||0006412: Export fails with "trim silence at end"|
|Description||Conditions: "End" marker is set past end of last region|
Project data: 32 bit float, 48kHz sample rate
Export CD format + trim silence from end (normalize, trim, WAV, 16bit 44.1kHz)
Export stops after processing, skips normalization phase and produces a file only 44 bytes long.
|Additional Information||If the End marker is moved to the end of the last region (so there is no silence to trim at end), export happens normally.|
Alternatively if "Trim silence at end" is deselected, export happens normally.
In this case, the recording was a single mono track, exported to stereo panned centre with a little reverb.
|Users sponsoring this issue|
Total Sponsorship = US$ 10
2016-09-15 19:19: efenstor (US$ 10)
||The problem occurs also for stem export, with 44.1 kHz, 32bit (version 4.1~dfsg-1build2).|
||I can confirm that this problem is still present in v5.3! It's a very annoying bug and need to be fixed at last! If "Trim silence at start" and/or "Trim silence at end" is ticked the output file is totally empty, containing only a header and nothing else. No other export parameter seems to influence the outcome, it is always empty.|
I can confirm this on Ardour 5.3.101, 64 bit, gcc4, UbuntuStudio 14.04 64 bit and Gentoo current.
This has nothing to do with: sample rate or session media bit depth or the position of the end marker in relation to last region. I had this happen like this:
- I created a new session, with jack as the audio engine, sample rate 44.1 kHz.
- I set session media to: 16 bit integer wave (4GB limit)
- I created a single audio track.
- recorded audio beginning at 2 seconds on the timeline and ending at 16 seconds.
- The session start marker was at 2 seconds and end marker at 16 seconds meaning they were exactly at the start and end borders of the recorded region. This is because I had Grid on when I made the recording.
- Then I selected Session / Export / Export To Audio Files. On the export window I selected the topmost export preset as described in the bug report (CD Redbook, Normalize peak, wav, 16bit 44.1 kHz). I opened the preset and ticked "Trim Silence At End", saved the preset and exported.
The file should have been 14 seconds long, but it was only 44 bytes as described by op. I noticed that the export window progress bar did not go from 0 % to 100% two times in a row as it should have but did it only once. It should have done it once for the mixdown and the second pass for normalization.
I then unticked normalization and left the Trim Silence At End ticked. This time the exported audio file is 16428 long (92 milliseconds says mediainfo). This is another anomaly.
Changing backend from Jack To Alsa does not change the export behaviour.
I then tested this on a current 64 bit Gentoo updated today and with Ardour 4.7 and I could not reproduce the problem. I then installed Ardour 5.3.101 on this same Gentoo machine and made a test session just like described above and the error was there again.
The export fails resulting in only the file header written to the file if ANY TWO of these are selected at the same time:
- Trim Silence At Start
- Trim Silence At End
I then left normalize and Trim Silence At Start ticked and tried all export file formats. Every time only the file header got saved or the file size was zero bytes (raw, flac).
I can confirm this issue exists with 5.3 and 5.3.126
If either trim silence and start or trim silence at end are enabled then the file exported is not valid and analysis does not occur if enabled.
||Issue still exists on 5.4.252.|
||Still not fixed in 5.5! I don't understand, is it so hard to fix? Or does nobody else in the world use the trim at export functions? I'll donate more, may be then it will get off the ground. Unfortunately I can't donate much as I live in Russia and quite tight on budget.|
||Somehow I can't sponsor. I click "Sponsor the issue" then nothing happens. I tried thrice. And I can't find where I can edit my payment data.|
||I donated $25 via the "Support Ardour" button on the main page of the site. I still can't find out how to support issues. Where can I see the instructions? If you want to be donated try to make it simple or at least understandable.|
||@Efenstor: The workaround is to create a range, dragging the range start and end markers to the start and end of the part of the session you want to export. Then rightclick on one of the range markers and select "Export Range" from the menu. I think this functionality is much more flexible than the trim start and end silence in export dialog :)|
||@mhartzel: Thanks for the advice! The problem is that I often cannot tell where my session ends, as I extensively use reverberation with long tails (my music is shamanistic folk-ambient). So I really need the automated cut of pure silence when exporting a complete song.|
@efenstor: I often deal with reverb tails by adding a fade-out right at the end of the tail so there's a visible indication. It also means there's a clear-cut end point. Long reverbs can take a long time to reach what could be considered silence.
@jrigg: That'll do, but still it's not a full equivalent. I don't know why but I like to have it neat, without any unnecessary silence but including every tiny bit of sound ))) Also, I usually do such "hard" editing things as song fadeouts at the CD mastering stage, that's not a work for the mixing. And one more thing: I don't use gaps, so the ends of the tails, no matter how long they are, usually continue to another song; it makes the listening experience more natural.
Trying to find where is the bug and fix it, I found a workaround for your use case. When you export with "trim silence at end" and "add silence at end" the exported file is valid. So, you can trim silence and add a silence of 2ms waiting for the bug is fixed..
I have a set of changes that should resolve this issue, I'm just waiting to get some time to do some further testing before commit.
You would think this sort of issue would not be hard to fix but sometimes you just never know until you try and fix it. Generally, if a bug like this has been around for a while it is because it is non-trivial to fix.
OK, this issue should now be resolved in master branch as of revision bd52d4e3. Can you please test in a nighly build >= 5.5.33 to confirm.
While fixing this issue I exported and then imported the exported files > 400 times, So I'm fairly confident this issue should be resolved but confirmation is very welcome.
||Confirmed, the trim functions work perfectly now! timbyr, thanks a lot!!!|
||Seems to work now, thanks timbyr :)|
||Also confirmed working in a quick test here - many thanks!|
||There is a chance the problem is not completely resolved (or it's another issue): when I'm exporting to Ogg Vorbis no trim happens, no matter the options, so I'm wondering, should it happen at all or the options are applied only when exporting to WAV?|
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.
|2015-07-04 12:04||anahata||New Issue|
|2015-07-06 12:46||anahata||Tag Attached: export|
|2016-01-09 10:24||scemama||Note Added: 0017772|
|2016-09-15 19:19||efenstor||Note Added: 0018650|
|2016-09-15 19:19||efenstor||Sponsorship Added||efenstor: US$ 10|
|2016-09-15 19:19||efenstor||Sponsorship Total||0 => 10|
|2016-09-15 21:54||mhartzel||Note Added: 0018653|
|2016-09-17 12:39||timbyr||Note Added: 0018674|
|2016-09-17 12:39||timbyr||Status||new => confirmed|
|2016-09-17 12:39||timbyr||Product Version||4.1 => 5.3|
|2016-09-28 16:48||paul||Relationship added||has duplicate 0007046|
|2016-09-28 16:48||paul||Relationship added||duplicate of 0005131|
|2016-10-31 21:42||mhartzel||Note Added: 0018896|
|2016-12-02 07:18||efenstor||Note Added: 0019101|
|2016-12-02 07:29||efenstor||Note Added: 0019102|
|2016-12-02 07:29||efenstor||Note View State: 0019102: private|
|2016-12-02 07:37||efenstor||Note Added: 0019103|
|2016-12-02 07:38||efenstor||Note View State: 0019103: private|
|2016-12-02 11:49||efenstor||Note View State: 0019103: public|
|2016-12-02 11:50||efenstor||Note View State: 0019102: public|
|2016-12-03 14:46||mhartzel||Note Added: 0019105|
|2016-12-04 10:56||efenstor||Note Added: 0019109|
|2016-12-04 11:21||jrigg||Note Added: 0019110|
|2016-12-04 11:23||jrigg||Note Edited: 0019110||View Revisions|
|2016-12-05 18:44||efenstor||Note Added: 0019112|
|2016-12-05 18:49||efenstor||Note Edited: 0019112||View Revisions|
|2016-12-05 18:49||efenstor||Note Edited: 0019112||View Revisions|
|2016-12-06 00:08||elgoun||Note Added: 0019114|
|2016-12-06 00:08||elgoun||Note Edited: 0019114||View Revisions|
|2016-12-06 03:07||timbyr||Note Added: 0019115|
|2016-12-06 03:52||timbyr||Note Added: 0019116|
|2016-12-06 03:52||timbyr||Status||confirmed => feedback|
|2016-12-06 14:53||efenstor||Note Added: 0019129|
|2016-12-06 14:54||efenstor||Status||feedback => resolved|
|2016-12-06 14:54||efenstor||Resolution||open => fixed|
|2016-12-06 14:54||efenstor||Assigned To||=> efenstor|
|2016-12-10 18:40||mhartzel||Note Added: 0019141|
|2016-12-11 11:36||anahata||Note Added: 0019143|
|2016-12-12 15:17||efenstor||Note Added: 0019152|
|2020-04-19 20:17||system||Note Added: 0023483|
|2020-04-19 20:17||system||Status||resolved => closed|