View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005884 | ardour | bugs | public | 2014-03-11 17:50 | 2016-04-03 21:10 |
| Reporter | motosega | Assigned To | x42 | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Summary | 0005884: errors when using timestretch tool - starts happening after timestretching some regions without errors | ||||
| Description | i 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 | ||||
| Tags | No tags attached. | ||||
|
|
Same error in 4.1 here (wanted 256, got 0) |
|
|
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? |
|
|
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 |
|
|
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'. |
|
|
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. |
|
|
It can also happen when performing extreme time-stretch. In that case the bug is the misleading error message. |
|
|
I see, yes, I usually see this with extreme stretches (3-4 times the original...) What maximum would you consider safe? |
|
|
wow. In my experience everything > 15-20% sounds weird already. 300-400% you really want http://hypermammut.sourceforge.net/paulstretch/ :) |
|
|
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. |
|
|
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). |
|
|
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 ;-) |
|
|
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.. |
|
|
Should be fixed since Ardour 4.7-524-gad73569 please test. |
|
|
Tested, and works for me. |
| 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 |
