|
2014-12-30 03:31
|
scrshot_audacity_1.png (130,714 bytes) |
|
2014-12-30 03:31
|
scrshot_audacity_2.png (83,032 bytes) |
|
|
In case it isn't clear from the description, I haven't had much success at isolating the "trigger" for this issue. It seems to be related (somewhat) to "complexity" -- ie, it's generally more likely as the number of tracks, buses, plugins, automation points - or just changes - goes up. Unfortunately I still don't have any better info about that, but I've done a little more experimenting... A few days after submitting this bug report I worked on a new recording session, using the same basic workflow described above. This time when I finished my initial edits, I exported a range twice, and got two completely _identical_ files -- that is, cmp(1) reports no differences. (This is what I would have expected actually, at least with dithering turned off, but it surprised me based on what I had seen before.) I quit Ardour and re-started it, opened the same session, and exported twice. Again the two files were exactly identical (to each other), as verified by cmp. They were not identical to the two files exported in the original editing session -- but the audio samples they contained disagreed by no more than +/- 1 LSB value, which (for now) I consider to be "matching". I quit and re-started Ardour a third time, and again exported twice. The new files were again identical to each other _and_ they were also identical to the two files exported in the second run of Ardour. A couple days later I opened the session again to work on a different part of the recording. I added some new markers and ranges, a new bus, a couple more LinuxDSP plug-ins, and a number of fader automation points. When I was finished with that round of changes, I exported the new stuff twice and got files that did *not* match -- the differences were similar to those reported in the original description (ie, random glitches). So then I went back and exported the first range (which I hadn't changed in the second round) again, and found that it was different in many places compared to the earlier exports by +/- 2 LSB values (larger dithering noise? I believe it was still turned off), and more importantly, it now also included random "glitch" differences, as compared to the 3 earlier sets of exports. So it seems that something I did with the later work triggered this issue, and it now affects all exports from this project. But in other sessions, the issue is present from the very first export, even with less "complexity". In addition, the most recent pair of exports exhibited a variation in about half the difference areas that I hadn't noticed before: Instead of decaying to zero samples, the original signal seems to be amplified. I'll upload another screenshot, showing one of these zoomed in. In this case I believe the second export ("exp2") is correct, as it agreed with a later third export (not shown) in this area. |
|
2015-01-08 05:18
|
scrnshot_audacity.3.png (87,843 bytes) |
|
|
I'm seeing the same issue with a recent nightly build (3.5-4392-gde85bfd, free version). The session I used for testing had exhibited the problem on 3.5.403 - and it has no plugins, which I thought should eliminate some variables. I'm willing to try debugging this if I can get some tips about possible strategies or areas to look at. (I have past experience with development in C for *NIX and with embedded real-time systems, but I don't know anything of Ardour's internal architecture.) |
|
|
That's very worrying. I did lots of export tests recently and was not able to reproduce. All are bit accurate (if dithering and normalization disabled) and I diff'ed them with original material (polarity invert). but I only checked wav (not flac, nor ogg). no time-offset, either. JACK 1.9.9.5 has a few issues regarding freewheeling/export. Can you reproduce the issue with a later version of JACK, or better yet: Export using the Ardour-nightly "Dummy" backend. What export format settings do you use? How large is the session? (since this is a session that's always reproducible it would be great, private by email is fine too). |
|
|
x42: Sorry, I did't notice that you had responded to this; I got an e-mail notification from Mantis only yesterday evening (2015-04-05 19:25:35 -0500). To answer your questions... For me, the appearance of the issue seems to be influenced in some way by "complexity". With very simple sessions - let's say, a couple tracks with one region each, no plugins, no automation - it's relatively unlikely. As I make changes (eg, splitting regions, shifting them around, adding buses, adding fader automation), it becomes more likely but still not guaranteed. However, many/most of the sessions I do involve a similar work-flow, and over the last 6 months or so I'd say the probability that I'll see the issue some time during work on a session is about 80-90%. Sometimes it's like my initial report, where the first exports from a session are okay (more precisely, no diffs seen in back-to-back exports) but I see the issue after quitting and restarting Ardour, but other times I see it right from the first couple export attempts in my initial editing session. Sometimes there are only a couple/few glitches in (let's say) 20 minutes of audio; other (most) times there are 10's (or more) in that time span. Sometimes the difference periods I see are the decay-to-zero type I initially reported; sometimes the amplitudes diverge (almost always the errant one is lower) but don't decay to zero; occasionally there is some other waveform distortion that I don't recognize. (Only once hace I seen the _increasing_ amplitude case I reported in the first note. Also keep in mind that I don't look at every single diff in detail -- often, there are too many, and/or I don't have time, so I just spot check them.) So I think it's possibly that one could do many tests with simple scenarios and short time spans and not see the issue. Of course it's also possible (likely) that there's something "special" about my environment or configuration that causes it, which would explain why there have been so few reports of it. Export settings: It varies, but typically the format is either wav or FLAC. I haven't seen any difference in behavior between the two. Here are some typical ones for me: - CD (Red Book): WAV, 44.1 kHz, 16-bit, shaped noise or no dithering - FLAC, 44.1 KHz, 16-bit, shaped noise or no dithering - FLAC, 44.1 KHz, 24-bit, no dithering I almost always export a range - by right-clicking a range marker. Since my last update I've set up a new computer with a faster CPU, more RAM, and a 9-year-old Delta 66 (PCI) sound card instead of the FastTrack Pro (USB). This one is also running Fedora with CCRMA, but it's F21, which comes with JACK 1.9.10 (so no more 1.9.9.5) and an RT-patched kernel: 3.14.29-200.rt26.1.fc21.ccrma.x86_64+rt On this machine I see pretty much the same thing, except that decay-to-zero differences are much less common than the other types. I also tried JACK1 on the original machine, with the same result. However I didn't report it because I built it from source and (because it was temporary) I did not follow the very clear and explicit instructions to install it on *top* of the JACK2 (package) installation - I set PATH and LD_LIBRARY_PATH on qjackctl and Ardour to point to my temporary JACK1, and from what I could see they picked up the intended binaries, but I realized the test still might not be valid. I've tried two nightly builds during the last 3 months, with the same result, but yes I can try another, and the "Dummy" back-end - probably later this week. I'd love to test the "full" version, but so far I've only used the free ones because I can't seem to get PayPal to cooperate for a subscription. (I've donated, but I know that doesn't count.) Been meaning to try building from source, but so far haven't had time... I came up with a way to compress the test session I mentioned in the previous note down to 230 MB, from 9 GB. Also mentioned here: https://community.ardour.org/node/8634#comment-39128 I might be able to reduce it even further (probably half or better) by removing regions that are not part of the test case and running clean-up (and verifying that the issue is still reproducible like that). Hoping to work on that later this week as well. |
|
|
Don3, please send me a link to the session (robin@gareus.org). |
|
|
I managed to reproduce it. The problem is coming from gain-fader automation (disable those and the issue disappears). There's no fix yet, but we're a step closer to understanding the issue. |
|
|
The issue can be explained with [fader] automation. A fix for this is now in Ardour 4.0-rc3-22-g96ce9c3 I have tested 3 exports since, and they're all good. Still, there may still be more to it [1]. It'd be great if you could confirm that Ardour 4.0-rc4 fixes this issue. PS. [1] there is more to it, declick on rec-stop for example see git 0ffde76 (but that has no effect during export or playback) |
|
|
Thanks x42 !! Ah, I see - locking issues - interesting... Okay, I will try to test as soon as I can. Seems I still cannot get past the subscription issue with PayPal (see https://community.ardour.org/node/2260, p.3 2015-01-28 13:18; I've written to them, but no response yet) to download a nightly build without the fade-outs. Or do the fade-outs not affect exporting? If they do, I'll try installing the deps and see if I can build locally. It may take me a couple days to get to it, unfortunately. |
|
|
should be fixed in 4.0-rc4. please test |
|
|
I've exported (twice each) 4 regions from 3 different sessions which previously exhibited differences/glitches, ranging in length from about 20 minutes to over an hour. (Long enough that the probability would have been high that at least a few would show up, if they were going to show up at all.) I've seen no differences in output samples so far (ignoring differences due to dither), which is a very good sign! In one case I exited and restarted A4, and exported a third time, and still no differences. (Previously there were (rare) occastions when exporting from one Ardour instance would produce matching files, but those would not match files produced by a later instance. Usually this only happened early on, like from the first editing session, but I thought I would try it anyway.) These sessions have between 2 and 6 recorded tracks. I'd like to try one with 8 tracks or more, but it seems I don't have any of those loaded on this machine right now, and the computer that has them is not nearby (and the network connection to it is slow) - so that will probably have to wait until I can get to it physically, which might be a few days. But the results I have now are very promising indeed. I'm planning to try this version for "production" work in the next week, to see how that goes. Note: I had numerous issues with JACK2 1.9.10 (current with Fedora 21), including a UI lock-up at the end of exporting, and UI unresponsiveness and a run-away jackd process when trying to restart after that. I built JACK1 0.124.1 from source, and with that I haven't seen a single issue so far. As a (minor) bonus, qjackctl and Ardour now show 100% DSP load during export, whereas JACK2 typically showed 8-10%. |
|
|
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. |
- Anonymous
