Is this a bug? N.B. Using Audacity v2.0.1 on Win 7 Home Premium SP1 64-bit
I am compiling a soundtrack for a new AV sequence. I have been using a Time Track to assist with the placement of the various sound files along the timeline. I move the Time Track down the project as I add new tracks to the mix. When I come to do a File Export to WAV for the project (7m 45s of playing time, 49 separate files laid out in an echelon formation), the prediction is that the export will take 5 minutes - and it starts off at a speed that suggests that is what it will take. I have not let it run to completion. If I delete the Time Track before exporting to WAV, the prediction is for 10 seconds and it takes just over 8 seconds (these latter numbers agree with all my previous experience).
What is going on here? Surely the presence of a Time Track cannot add that much overhead to the export, can it?
If I have nine audio tracks and a Time Track, export is about five times longer than without the Time Track, and about ten times longer with 18 tracks.
Time Track does resampling. If you change the project rate to something else, export will also be slower.
Re-sampling what? …and why? I haven’t changed any sample rates. All my work is done at 44100Hz, 32-bit Float internally and exported to 44100HZ 16-bit PCM WAV externally. The 32-bit to 16-bit “re-sampling” should be the same in both cases. Where is the extra time (massive extra time) coming from?
All I was using the Time Track for was to place a timeline against the track I was currently working on. It saved moving the working track up to the top of the window to sit it against the timeline and then moving back down again after completing the work on it. Ergonomically efficient, but not processor efficient, it would seem!
How else does it change the pitch and length while keeping the same sample rate?
I don’t think I’m wrong. The Time Track code includes Resample.h. Change the “High-quality conversion” to “Fast Sinc Interpolation” in Quality Preferences and you should see a faster export with your Time Track present.
I did not realise that you were not actually using the Time Track for a time warp. Do you want to vote for some kind of movable ruler then? Or vertical grid lines?
So I suppose we have to ask the question, should Time Track be doing a no-change resample (and so marginally degrading the quality) when it’s set not to make a time warp? Probably that is such a rare case that they developers would not want to code it?
A “Ruler” feature most definitely gets my vote! All I want is the timeline marks in a track that I can keep dragging down the window as I add and work on each new addition to the soundtrack project. I thought that was what I was getting with the Time Track (I didn’t read the manual. I just added one to see what it was and it seemed to be just what I was looking for!).
I’m less sure about vertical grid lines. I suspect these could get confused with the cursor line. Now, if the cursor line displayed across all tracks(*) and not just the selected track(s), that might prove an acceptable alternative solution…
(*) - irrespective of whether they have any sound at that position, of course!
As it stands now, it seems that the cursor appears in the selected track(s) and additionally in the focused track (the one that has the yellow border). Bill calls that focus cursor a “phantom” cursor. I feel there is a good case that the cursor should be in all the tracks, with the proviso that the cursor in the selected tracks is more prominent.
I feel even more strongly that when Sync-Lock Tracks is enabled, there should be a sync-lock cursor in unselected tracks analogous to the sync-lock region in unselected tracks. But if we had “guide cursors” in all tracks even if sync-lock is off, then probably the lack of a “sync-lock cursor” would not matter.
All my work is done at 44100Hz, 32-bit Float internally and exported to 44100HZ 16-bit PCM WAV externally. The 32-bit to 16-bit “re-sampling” should be the same in both cases. Where is the extra time (massive extra time) coming from?