When exporting an audio file and tick the box 'only render marked region' the file created is shorter than the marked region by a small amount.
This makes true sample accurate editing impossible and tasks that involve seamless joining of adjacent tracks for a CD impossible.
This is related to all versions of T2 (and also to T1 but the gap is smaller).
BR - Major BIG bug - export/ create an audio file...
-
- KVRAF
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
-
flanneljammies flanneljammies https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=19969
- KVRist
- 462 posts since 5 Apr, 2004 from Madison WI
Yes, I noticed this last week when I was rendering audio from a MIDI file. I couldn't figure out why looping audio was getting off toward the end of the song until I zoomed in and noticed that the rendered audio wasn't the full two bars. Not that big of a deal in this case because I just pasted and then dragged to snap to the bar marker, but still. It sure could be a real hassle with something other than drum beats.
At home, he's a tourist...
-
- KVRAF
- 3299 posts since 7 May, 2004 from Athens, Greece
Yep, its true, at least for T1.6
If I go insane, please don't put your wires in my brain
-
- KVRAF
- 4908 posts since 10 Aug, 2004 from Colorado Springs
Just a suspicion,
Is this related to midi export to audio only; where possibly the export is only counting the start of the first midi note in the marked region and the last note-off message in the marked region?
Can you make the problem disappear by turning off the 'trim silence' option on export?
-Scott
Is this related to midi export to audio only; where possibly the export is only counting the start of the first midi note in the marked region and the last note-off message in the marked region?
Can you make the problem disappear by turning off the 'trim silence' option on export?
-Scott
-
flanneljammies flanneljammies https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=19969
- KVRist
- 462 posts since 5 Apr, 2004 from Madison WI
That was the first thing I tried... no dice.rockstar_not wrote:Can you make the problem disappear by turning off the 'trim silence' option on export?
At home, he's a tourist...
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
"Big" is certainly relative. 
Yeah, if it's a bug (and it seems to be) a fix is clearly necessary.
But it's likely been there since 1.x, and nobody's mentioned it yet (at least not that I've noticed)... with all those users logging all those hours, surely there would have been an uproar if it was considered "Big"?
To be clear: I'm not saying we should just live with it. If it's a bug, it needs to be fixed. But it's always interesting seeing the different weight people put on various BR and FR.
Yeah, if it's a bug (and it seems to be) a fix is clearly necessary.But it's likely been there since 1.x, and nobody's mentioned it yet (at least not that I've noticed)... with all those users logging all those hours, surely there would have been an uproar if it was considered "Big"?
To be clear: I'm not saying we should just live with it. If it's a bug, it needs to be fixed. But it's always interesting seeing the different weight people put on various BR and FR.
-
- The Teach
- 8273 posts since 23 Jul, 2002 from flatness
confirmed ...
... i vaguely seem to remember this (or similar) coming up during testing but cant find anything concrete at the moment ...
slainte
rob
... i vaguely seem to remember this (or similar) coming up during testing but cant find anything concrete at the moment ...
slainte
rob-
- KVRian
- 1272 posts since 11 Apr, 2002 from Nashville, TN
Maybe we should come up with a scale to describe the severity of bugs. I suggest using descriptive tags in combination with a hexidecimal suffix followed by either a small "i" to denote minor or a capital "I" to denote "major".
TAG | Hex | (i or I)
minisule 0-F
very tiny 0-F
tiny 0-F
small 0-F
pretty small 0-F
moderate 0-F
notable 0-F
sizable 0-F
big 0-F
very large 0-F
huge 0-F
immense 0-F
gargantuan 0-F
ultimate 0-F
Here is a portion of the scale to help demonstrate...
Displayed in increasing severity...
...very tiny F I
tiny 0 i
tiny 0 I
tiny 1 i
tiny 1 I
tiny 2 i
tiny 2 I
tiny 3 i
tiny 3 I
tiny 4 i
tiny 4 I
tiny 5 i
tiny 5 I
tiny 6 i
tiny 6 I
tiny 7 i
tiny 7 I
tiny 8 i
tiny 8 I
tiny 9 i
tiny 9 I
tiny A i
tiny A I
tiny B i
tiny B I
tiny C i
tiny C I
tiny D i
tiny D I
tiny E i
tiny E I
tiny F i
tiny F I
small 0 i
small 0 I
small 1 i
small 1 I
small 2 i
small 2 I
small 3 i
small 3 I
small 4 i
small 4 I
small 5 i
small 5 I
small 6 i
small 6 I
small 7 i
small 7 I
small 8 i
small 8 I...
I also suggest the following abbreviations to make things simpler...
minisule (m)
very tiny (vt)
tiny (t)
small (s)
pretty small (ps)
moderate (M)
notable (N)
sizable (S)
big 0-F (B)
very large (VL)
huge (H)
immense (I)
gargantuan (G)
ultimate 0-F (U)
I think this will help make things SO MUCH CLEARER by allowing us to avoid sloppy desciptions of bug severities. This will also help Mackie prioritize!
For example, if a bug is classified as a ps7i, no one need get their panties in a wad. Although an VL0i and above would be a real cause for concern.
TAG | Hex | (i or I)
minisule 0-F
very tiny 0-F
tiny 0-F
small 0-F
pretty small 0-F
moderate 0-F
notable 0-F
sizable 0-F
big 0-F
very large 0-F
huge 0-F
immense 0-F
gargantuan 0-F
ultimate 0-F
Here is a portion of the scale to help demonstrate...
Displayed in increasing severity...
...very tiny F I
tiny 0 i
tiny 0 I
tiny 1 i
tiny 1 I
tiny 2 i
tiny 2 I
tiny 3 i
tiny 3 I
tiny 4 i
tiny 4 I
tiny 5 i
tiny 5 I
tiny 6 i
tiny 6 I
tiny 7 i
tiny 7 I
tiny 8 i
tiny 8 I
tiny 9 i
tiny 9 I
tiny A i
tiny A I
tiny B i
tiny B I
tiny C i
tiny C I
tiny D i
tiny D I
tiny E i
tiny E I
tiny F i
tiny F I
small 0 i
small 0 I
small 1 i
small 1 I
small 2 i
small 2 I
small 3 i
small 3 I
small 4 i
small 4 I
small 5 i
small 5 I
small 6 i
small 6 I
small 7 i
small 7 I
small 8 i
small 8 I...
I also suggest the following abbreviations to make things simpler...
minisule (m)
very tiny (vt)
tiny (t)
small (s)
pretty small (ps)
moderate (M)
notable (N)
sizable (S)
big 0-F (B)
very large (VL)
huge (H)
immense (I)
gargantuan (G)
ultimate 0-F (U)
I think this will help make things SO MUCH CLEARER by allowing us to avoid sloppy desciptions of bug severities. This will also help Mackie prioritize!
For example, if a bug is classified as a ps7i, no one need get their panties in a wad. Although an VL0i and above would be a real cause for concern.
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
classic!
And if that's a jab at me, I certainly deserve it.
-
- KVRian
- 1272 posts since 11 Apr, 2002 from Nashville, TN
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Ah, a major tiny joke!
-
- KVRAF
- Topic Starter
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
rock - lol
I thought it was big because sample accurate editing and rendering is impossible as it stands, which for a 'professional' sequencer is a joke. The fact that no one has noticed in over 2 years (can't speak for before T1.6) means it can't be that big a deal, true.
Would anyone like me to change the word BIG in the title?
I thought it was big because sample accurate editing and rendering is impossible as it stands, which for a 'professional' sequencer is a joke. The fact that no one has noticed in over 2 years (can't speak for before T1.6) means it can't be that big a deal, true.
Would anyone like me to change the word BIG in the title?
-
flanneljammies flanneljammies https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=19969
- KVRist
- 462 posts since 5 Apr, 2004 from Madison WI
Maybe not big, but an annoying bug for sure that should be fixed. Has anyone tried this with an audio region instead of MIDI with the same results?
At home, he's a tourist...
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
I definitely understand its importance and agree that it should be fixed. Hope that was conveyed.
I think the reason nobody's noticed is simple: very few people use Tractkion for creating their sample-accurate loops, and when they do, the material (just in terms of composition!) may have an "empty" audible space at the end, meaning the extra couple samples wouldn't be detectable.
Most people who are T users are still using other audio editors for creating loops and so forth, and those of us who will resize a clip and then use it as a "loop" also often do small cross-fades instead of sample-accurate looping.
And of course, when rendering a song, nobody notices an extra couple samples at the end.
Greg
I think the reason nobody's noticed is simple: very few people use Tractkion for creating their sample-accurate loops, and when they do, the material (just in terms of composition!) may have an "empty" audible space at the end, meaning the extra couple samples wouldn't be detectable.
Most people who are T users are still using other audio editors for creating loops and so forth, and those of us who will resize a clip and then use it as a "loop" also often do small cross-fades instead of sample-accurate looping.
And of course, when rendering a song, nobody notices an extra couple samples at the end.
Greg
Last edited by Lunch Money on Thu Feb 23, 2006 6:29 pm, edited 1 time in total.
-
- The Teach
- 8273 posts since 23 Jul, 2002 from flatness
rob