View Issue Details

IDProjectCategoryView StatusLast Update
0006412ardourbugspublic2020-04-19 20:17
Reporteranahata Assigned Toefenstor  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version5.3 
Summary0006412: Export fails with "trim silence at end"
DescriptionConditions: "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 InformationIf 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.
Tagsexport

  Users sponsoring this issue
Sponsors List Total Sponsorship = US$ 10

2016-09-15 19:19: efenstor (US$ 10)
  Users sponsoring this issue (Total Sponsorship = US$ 10)

Relationships

duplicate of 0005131 closedefenstor enabling "Trim silence at the end" produce empty export 
has duplicate 0007046 closedefenstor Export with trim silence fails 

Activities

scemama

2016-01-09 10:24

reporter   ~0017772

The problem occurs also for stem export, with 44.1 kHz, 32bit (version 4.1~dfsg-1build2).

efenstor

2016-09-15 19:19

reporter   ~0018650

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.

mhartzel

2016-09-15 21:54

reporter   ~0018653

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:
- Normalize
- 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).

timbyr

2016-09-17 12:39

developer   ~0018674

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.

mhartzel

2016-10-31 21:42

reporter   ~0018896

Issue still exists on 5.4.252.

efenstor

2016-12-02 07:18

reporter   ~0019101

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.

efenstor

2016-12-02 07:29

reporter   ~0019102

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.

efenstor

2016-12-02 07:37

reporter   ~0019103

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.

mhartzel

2016-12-03 14:46

reporter   ~0019105

@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 :)

efenstor

2016-12-04 10:56

reporter   ~0019109

@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.

jrigg

2016-12-04 11:21

reporter   ~0019110

Last edited: 2016-12-04 11:23

@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.

efenstor

2016-12-05 18:44

reporter   ~0019112

Last edited: 2016-12-05 18:49

@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.

elgoun

2016-12-06 00:08

reporter   ~0019114

Last edited: 2016-12-06 00:08

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..

timbyr

2016-12-06 03:07

developer   ~0019115

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.

timbyr

2016-12-06 03:52

developer   ~0019116

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.

efenstor

2016-12-06 14:53

reporter   ~0019129

Confirmed, the trim functions work perfectly now! timbyr, thanks a lot!!!

mhartzel

2016-12-10 18:40

reporter   ~0019141

Seems to work now, thanks timbyr :)

anahata

2016-12-11 11:36

reporter   ~0019143

Also confirmed working in a quick test here - many thanks!

efenstor

2016-12-12 15:17

reporter   ~0019152

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?

system

2020-04-19 20:17

developer   ~0023483

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.

Issue History

Date Modified Username Field Change
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
2016-12-05 18:44 efenstor Note Added: 0019112
2016-12-05 18:49 efenstor Note Edited: 0019112
2016-12-05 18:49 efenstor Note Edited: 0019112
2016-12-06 00:08 elgoun Note Added: 0019114
2016-12-06 00:08 elgoun Note Edited: 0019114
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