Audacity "connects the dots" when you zoom in

[brian-armstrong]

Hi,

I'm reporting a bug I've noticed on the OSX version of Audacity, but it likely applies to all versions.

When you zoom in close enough to see individual samples, Audacity renders them with lines connecting them. However, DSP tells us specifically that you CAN'T do this. Audacity should instead plot these with a stem plot like Matlab does, or at least give the option to do so.

Otherwise, this is great software! Thanks for all the hard work.

[kozikowski]

I'm reporting a bug I've noticed on the OSX version of Audacity

It's not a bug. The software is working as designed. It may be awkward or an error, but not a bug.

Koz

[brian-armstrong]

I'm reporting a bug I've noticed on the OSX version of Audacity

It's not a bug. The software is working as designed. It may be awkward or an error, but not a bug.

Koz

Ah, that's a good point. Should I have posted this elsewhere?

[steve]

Should I have posted this elsewhere?

There's no perfect fit. I think "Audio Technology > Audio Processing" is the closest we have, so I've moved the topic here.

When you zoom in close enough to see individual samples, Audacity renders them with lines connecting them. However, DSP tells us specifically that you CAN'T do this. Audacity should instead plot these with a stem plot like Matlab does, or at least give the option to do so.

Could you post a screenshot showing how Matlab displays samples.

Probably the most "truthful" way to display samples would be like this:

Audio samples as hex values

hex.png (17.48 KiB) Viewed 1401 times

but that's pretty useless in terms of "visualising" the data, which is the whole point of having a graphic representation of the audio track.
There's a related discussion here which you may find interesting: http://forum.audacityteam.org/viewtopic ... =converter

[brian-armstrong]

I have made an attempt to show what I mean.

Code: Select all

diff --git a/src/TrackArtist.cpp b/src/TrackArtist.cpp
index 7d4385d..584b856 100644
--- a/src/TrackArtist.cpp
+++ b/src/TrackArtist.cpp
@@ -1363,12 +1363,13 @@ void TrackArtist::DrawIndividualSamples(wxDC &dc, int leftOffset, const wxRect &
    }
 
    // Draw lines
-   for (decltype(slen) s = 0; s < slen - 1; s++) {
+   for (decltype(slen) s = 0; s < slen; s++) {
       AColor::Line(dc,
                    rect.x + xpos[s], rect.y + ypos[s],
-                   rect.x + xpos[s + 1], rect.y + ypos[s + 1]);
+                   rect.x + xpos[s], rect.y + (rect.height/2));
    }
 
+
    if (showPoints)
    {
       // Draw points where spacing is enough

http://imgur.com/a/Ul0yC shows it at various zoom levels. The first is before showIndividualPoints engages, and it looks like it's kind of an awkward transition to this style. Also weird is the "space filling" and aliasing you see at lower zoom levels, though I think it looks ok zoomed far in. Might make an interesting non-default render option

[steve]

I have made an attempt to show what I mean.

That works nicely at some zoom levels

firsttrack015.png (9.46 KiB) Viewed 1393 times

though as you say, it looks a bit strange when there's aliasing at lower zoom levels

firsttrack016.png (10.06 KiB) Viewed 1393 times

and also a bit sparse at maximum zoom

firsttrack017.png (8.47 KiB) Viewed 1393 times

and of course, those vertical lines don't really exist either.

Might make an interesting non-default render option

Yes I agree it could be an interesting non-default option, though I think it would need to be tweaked so as to avoid the aliasing.
Perhaps bring in the vertical lines only when the dots are show?
(around line 1365 of TrackArtist.cpp)

Code: Select all

   if (showPoints)
   {
      // Draw points where spacing is enough
      const int tickSize = bigPoints ? 4 : 3;// Bigger ellipses when draggable.
      wxRect pr;
      pr.width = tickSize;
      pr.height = tickSize;
      //different colour when draggable.
      dc.SetBrush( bigPoints ? dragsampleBrush : sampleBrush);
      for (decltype(slen) s = 0; s < slen; s++) {
         if (ypos[s] >= 0 && ypos[s] < rect.height) {
            pr.x = rect.x + xpos[s] - tickSize/2;
            pr.y = rect.y + ypos[s] - tickSize/2;
            dc.DrawEllipse(pr);
         }
      }
      // Draw vertical lines
      for (decltype(slen) s = 0; s < slen; s++) {
         AColor::Line(dc,
                     rect.x + xpos[s], rect.y + ypos[s],
                     rect.x + xpos[s], rect.y + (rect.height/2));
      }
   }
   else {
      // Draw joining lines
      // At this zoom level, linear interpolation is generally a reasonable approximation
      // of the analog waveform.
      for (decltype(slen) s = 0; s < slen - 1; s++) {
         AColor::Line(dc,
                     rect.x + xpos[s], rect.y + ypos[s],
                     rect.x + xpos[s + 1], rect.y + ypos[s + 1]);
      }
   }

[steve]

Just thinking, "Matlab" is a registered trademark, so we may not be able to call such an option "Matlab style samples". Any ideas what this style of graphic representation could be called?

[brian-armstrong]

Yes I agree it could be an interesting non-default option, though I think it would need to be tweaked so as to avoid the aliasing.
Perhaps bring in the vertical lines only when the dots are show?

Hm, I think that's a good improvement. I do like the stem version at one zoom level up from there, though.

[steve]

A related question is: where exactly should the "dot" be located? Should it be at the beginning of the sample period (as now), in the middle, somewhere else, why?

[brian-armstrong]

Just thinking, "Matlab" is a registered trademark, so we may not be able to call such an option "Matlab style samples". Any ideas what this style of graphic representation could be called?

I believe these are often called Stem plots.

https://en.wikibooks.org/wiki/Digital_S ... Stem_Plots
https://www.mathworks.com/help/matlab/ref/stem.html