View Issue Details

IDCategoryLast Update
0005884bugs2016-04-03 21:10
ReportermotosegaAssigned Tox42 
Reproducibilityalways 
Status feedbackResolutionopen 
Product Version 
Fixed in Version 
Summary0005884: errors when using timestretch tool - starts happening after timestretching some regions without errors
Descriptioni have hit a problem with using the timestretch tool, i have a project whithin with i can no longer timestretch audio. after several sucessfull timestretches i am no longer able to timestretch regions

in the ardour log i see this message:
[ERROR]: An error occurred while executing time stretch operation
[ERROR]: tempoize: error reading data from 04 The Good Egg.8@85 at 1336752 (wanted 256, got 144)

i can provide the project file on request
TagsNo tags attached.

Activities

zettberlin

2015-06-28 15:03

reporter   ~0016816

Same error in 4.1 here (wanted 256, got 0)

Oliver

2015-11-18 18:09

reporter   ~0017622

Same problem with ardour 4.4 on Xubuntu 14.04 LTS.

More detailed description: I was working on fitting a vocal track with slightly different timing over other, existing tracks by cutting, moving and stretching it. I did some five or six such steps yesterday, all successfully.

Today I wanted to tweak a little more, and the following error appeared in the log window when I tried to stretch a track: "[ERROR]: tempoize: error reading data from Vocals_Mercury.16 at 3296527 (wanted 256, got 0)
[ERROR]: An error occurred while executing time stretch operation"

Repeating the attempt gave the same result.

Possibly it occurs when an already stretched region is stretched again?

x42

2015-11-18 18:37

administrator   ~0017623

It occurs when an already stretched region is stretched again *after moving it to a new track and after cleaning up unused files* ?

Timestretching goes back to the original source. It is not performed incrementally to the previously stretched audio.
Ardour keeps a reference to the original un-stretched data and won't delete it; ..except that relationship is can be lost in some cases. That's a bug.

To reproduce:

0) new session, add an audio track
1) record some region
2) time-stretch it
3) move the region to the dropzone -> new track
4) Session > Cleanup > Cleanup Unused Sources
5) time-stretch the region again -> fail


Instead of (3) various more complex alternative trigger this, as well. e.g remove the region. then re-add the time-stretched from the region-list

Oliver

2015-11-18 20:38

reporter   ~0017624

I indeed can reproduce the way described by x42 with a fresh session.

In my case reported above, I was working with time stretching only inside one track. I definitely did not do a Session > Cleanup, but might have done 'Remove unused' in the region drawer on the right (cannot remember for sure).

I did: a) slice up the audio in multiple regions, b) move around the regions within the track, c) also cut out some pieces, and c) stretched some regions. Then, on next day, I wanted to continue this way, and the error occurred.

I tried to do the same now, within one track of a fresh session, but could not get the same error, even if I do 'Remove unused'.

zettberlin

2015-11-18 21:54

reporter   ~0017626

Since I have about 3 TB diskspace I ceased to do the cleanup action for about a year now.

Still I have that error once in while. And I see it while stretching regions the first time.

x42

2015-11-18 22:12

administrator   ~0017627

It can also happen when performing extreme time-stretch. In that case the bug is the misleading error message.

zettberlin

2015-11-20 23:03

reporter   ~0017649

I see, yes, I usually see this with extreme stretches (3-4 times the original...) What maximum would you consider safe?

x42

2015-11-20 23:28

administrator   ~0017650

wow. In my experience everything > 15-20% sounds weird already.

300-400% you really want http://hypermammut.sourceforge.net/paulstretch/ :)

Oliver

2015-11-21 07:17

reporter   ~0017652

In my case though, I did only small stretches, a few percent, so the origin of the error is probably one of the other causes mentioned.

x42

2015-11-21 09:24

administrator   ~0017653

The numbers in the error message "wanted 256, got 0" are audio-samples. The message is from rubberband (the timestretch tool).

"got 0" means file was missing.

"got 144" (or some other non-zero number) means too extreme stretch.

(there is a one in 256 chance that "got 0" can also be a too extreme stretch).

zettberlin

2015-11-21 20:45

reporter   ~0017656

I use extreme stretching to create sounds, the original intention to correct tempo a bit is more often used I guess ;-)

Anyway, if the stretching-lib is not designed for extreme measures, maybe a stretch-tool could be tweaked a bit to discourage unsafe operations with a warning or so ?

Paulstretch is cool, anyway it would be great to have something that can be applied to regions in ardour directly. While I do crazy stuff with the stretcher I still like it to adapt my madness to the arrangement and measure in ardour ;-)

pavelpotocek

2016-03-02 13:38

reporter   ~0018034

I found the cause of this bug and probably also 0005697, 0004928, 0004773. The problem is that when creating a new region from an existing one, in 'libs/ardour/region.cc', constructors 'Region::Region' do not set '_master_sources' correctly. It is instead set to be equal to _sources (by Region::use_sources), which is incorrect whenever the two aren't equal.

Steps to reproduce:
1. create a new region by importing a file,
2. compress the region with the stretch tool,
3. cut it somewhere with the cut tool,
4. stretch the first half,
5. stretch the second half.

Step 4. results in a stretched region, but a wrong part of the file has been stretched by a wrong amount,
Sted 5. results in no change and a message
[ERROR]: tempoize: error reading data from ???? at ???? (wanted 256, got 0)
[ERROR]: An error occurred while executing time stretch operation

The fix seems to be to change the lines 'use_sources (other->_sources);' to 'use_sources (other->_sources); set_master_sources(other->_master_sources);' in region.cc. This change seems a bit smelly though, since the second line undoes half the work the first line did.

I'm sorry for the format of this message and the included "diff". I'm not familiar with the codebase nor this bug tracker at all..

x42

2016-04-03 16:52

administrator   ~0018129

Should be fixed since Ardour 4.7-524-gad73569
please test.

pavelpotocek

2016-04-03 21:10

reporter   ~0018130

Tested, and works for me.

Issue History

Date Modified Username Field Change
2014-03-11 17:50 motosega New Issue
2015-06-28 15:03 zettberlin Note Added: 0016816
2015-11-18 18:09 Oliver Note Added: 0017622
2015-11-18 18:37 x42 Note Added: 0017623
2015-11-18 20:38 Oliver Note Added: 0017624
2015-11-18 21:54 zettberlin Note Added: 0017626
2015-11-18 22:12 x42 Note Added: 0017627
2015-11-20 23:03 zettberlin Note Added: 0017649
2015-11-20 23:28 x42 Note Added: 0017650
2015-11-21 07:17 Oliver Note Added: 0017652
2015-11-21 09:24 x42 Note Added: 0017653
2015-11-21 20:45 zettberlin Note Added: 0017656
2016-03-02 13:38 pavelpotocek Note Added: 0018034
2016-04-03 16:52 x42 Note Added: 0018129
2016-04-03 16:52 x42 Assigned To => x42
2016-04-03 16:52 x42 Status new => feedback
2016-04-03 21:10 pavelpotocek Note Added: 0018130