#18 Inter-application copy/paste of layer data

[Craig Stuart Sapp]

It would be extremely useful if layer data could
be copy/pasted between Sonic Visualiser and other
programs, such as a text editor or a spreadsheet
application such as Excel.

The copy/paste would work in a similar manner to
how it can currently be done between layers in
SV as illustrated in the attached image. In the
example case the first 10 time instants from the
top pane are copied and pasted into another layer
in the bottom pane. If this layer data were
pasted into a text editor, it would look like
this:

1.578956916 1
2.461315192 2
3.227573696 3
3.808072562 4
4.388571428 5
4.876190476 6
5.526349206 7
6.339047619 8
6.826666666 9
7.198185941 10

The second attached image shows what the data
would look like after pasting into Excel. Also,
demonstrations of how the pasted data would be
used -- such as a column of data which calculates
a tempo between events, and a plot of that data.

As an aside, note that the time data has too
many significant digits (at least for 44.1 kHz
sampling rate). The smallest time increment
at 44.1 kHz is 23 microseconds:
0.000023
However the annotation export layer times go
into the nano seconds:
0.000023000
So the last three digits of the time values
are not significant or useful in calculating
which sample in the soundfile the time instant
belongs to. So in this example case, it would
be somewhat preferred if the pasted data looked
like this:

1.578957 1
2.461315 2
3.227574 3
3.808073 4
4.388571 5
4.876190 6
5.526349 7
6.339048 8
6.826667 9
7.198186 10

Pasting layer data into Sonic Visualiser from another
application would also be useful, but I would prefer
the outgoing direction (SV->other program) to be set up
first since that should be easier to implement (don't
need to do parsing/error checking on outgoing data).

[Craig Stuart Sapp]

Example of copy/paste between layers in SV

[Craig Stuart Sapp]

Example of pasting layer data into a spreadsheet

[Chris Cannam]

Logged In: YES
user_id=13489

Agreed this would be nice, will look into it.

I don't quite understand your point about decimal precision.
1/44100 of a second is approximately 22676 nanoseconds, not
23000. It seems to me the more decimal places, the better.

[Craig Stuart Sapp]

Logged In: YES
user_id=262664

> 1/44100 of a second is approximately 22676
> nanoseconds, not 23000. It seems to me the
> more decimal places, the better.

I am thinking mostly in terms of file size and
readability. But it is not a problem whichever
way the time values are written, so that was not
an important point. I can live with three extra
digits of precision :-).

If the sampling rate is known to be fixed, then
the high time resolution is not necessary. At
44100 Hz sampling rate, the samples are spaced

.0000226757369614512471655328798185941043083900226757369614512471655\ 32879818594104308390022675736961451247165532879818594104308390022675\ 73696145124716553287981859410430839002267573696145124716553287981859\ 41043083900226757369614512471655328798185941043083900226757369614512\ 47165532879818594104308390022675736961451247165532879818594104308390\ 02267573696145124716553287981859410430839002267573696145124716553287\ 98185941043083900226757369614512471655328798185941043083900226757369\ 6145124716553287981859410...

seconds apart (more or less :-).

So what I am saying, is that if you know that the
sampling rate is 44100 Hz, and the time value in the
data file is either:
454.889024943
or
454.889025
It would not matter, because both of them can be
used to calculate which sample in the file the
data is linked to:

454.889024943 * 44100 = 20060605.9999863
454.889024 * 44100 = 20060606.0025

In this case, nanosecond resolution is closer to the
integer sample, being 0.0000137 samples close. While the
microsecond resolution one is 0.0025 samples close to the
correct value. But they are both so close that you
could not confuse the fact that they both are intended
to be linked to sample 20060606, rather than to 20060607 or
to 20060605.

Notice that I am not intending the other way around which
you might be thinking of: when going from sample numbers to
time values, you need 1/44100 to be exact as possible to
avoid round-off errors. using 23000 ns as one sample time
duration is a lot worse than using 22676 ns:
0.000023000 * 20060606 = 461.393938000
0.000022676 * 20060606 = 454.894301656
If you do that, you would end up with a time difference
between the two methods of 6.499636344 seconds by the
end of 7.5 minutes of audio!

In that case, 23000 ns has two significant digits, and
22676 has 5, so it is better. If you use 23000 as the
sample multiplier, then you can only trust the first
two digits of the result:
454.889024943 --> 450.000000000 which just misses
the round up to 460.000000000.
Using 22676 as the multiplier, you can trust the first
5 digits:
454.889024943 --> 454.890000000
Where any digits after .89 (1/100 of a second accuracy
after 7.5 minutes) is garbage due to rounding 1/44100
to the nearest nanosecond.

1.0/44100.0 in a double float is a lot better with
about 50 significant bits, or about 16 digits.
So you could reliably measure the time value at sample
20060606 to be
454.889 024 943 310 7
which is accurate to the around the picosecond level
after 7.5 minutes.

If you use a plain float, that has about 7
significant digits, calculating:
20060606 / 44100
in float is only good to about:
454.88902
which is accurate to about 10 microseconds.