Scrub using only the waveform

[kra-mo]

I don't know what the reason for adding a separate progress bar was, but I don't see much value in it.

Doing something like Amberol, where the waveform of the entire file is displayed in full and you can scrub on that seems less distracting and more useful. I feel like only reason you'd need the waveform anyway is to skip a part of silence or something like that. I also think this is what was intended in the original mockup.

[vixalien]

quoting @allanday:

The waveform was always going to be the trickiest aspect of the design and what you have right now makes sense as a first cut. There is a simplicity in the original design which I find attractive, but it would also require us to figure out how to draw a compressed wave form for very long audio files. Also you're right that precise seeking could be an issue there.

The alternative would be to do something very similar to what you have: have a fixed scale for the waveform and allow it to be wider than the view, and then allow it to be scrolled horizontally. Maybe we could have a scroll bar in there, like we do with normal scroll views. This would also require that it be possible to click on a position in the waveform in order to start playback at that point.

I'm not sure of the correct™ thing to do in this case (yet)

[kra-mo]

Ah, I see. So this is mostly just a technical issue?

For the precise scrubbing part, I think the +/- 10s buttons work well enough, I'm not sure if there is a use case where you need more precision when using an app like this.

[kra-mo]

This might not be worth it by the way, but how about progressively loading the waveform?

As in, a waveform is shown for the full length of the file, but it only shows

.|.|........

at the start. And then as it's loading, it completes.

[vixalien]

This might not be worth it by the way, but how about progressively loading the waveform?

yea this could be done, but I'm not sure how well the app will will handle thousands of signals getting fired.

[vixalien]

This might not be worth it by the way, but how about progressively loading the waveform?

Decibels now loads the waveform progressively.

For the precise scrubbing part, I think the +/- 10s buttons work well enough, I'm not sure if there is a use case where you need more precision when using an app like this.

So the issue is "fixed"?

[kra-mo]

Well, the app still displays a separate progress bar. Removing that and displaying the waveform for the entire length of the audio file is what the initial mockup and this issue was proposing.

[vixalien]

Ah right, while that can be done. I'm not sure if it's the right thing to do.

This is after I learned some people use Decibels to listen to long audio files (podcasts, lectures) and the waveform may get too truncated when fitted into a window.

[kra-mo]

What issue would that bring? Or what does too truncated mean?

[vixalien]

It means that the waveform will be short, with the audio itself being long. It means it won't be possible to seek accurately within the audio if it is too long.

Because the primary use of using a waveform is so that silence can be skipped in long audios (podcasts or lectures) it makes the feature worthless.

[kra-mo]

Hmm, I guess so. I wonder if it would be possible to magnify the area around the current play position if the audio is too long instead. It would keep the elegance, but allow for the skipping over of silence. (As well as skipping even longer silence quicker.)

Something like this amazing mockup I just gimped up.

Though this would probably be hard to implement.

[vixalien]

Yea, that is indeed going to be hard. I wonder what about just removing the scale for now though.

The issue is that if the scale is removed, there is still no way of knowing where we are in the audio (progress)

[BlobCodes]

After some thinking, this is my proposal to fix this issue.

We could show the song progress while showing the waveform by setting the position of the song highlighting to the display width multiplied with the song progress.

This explanation sounds way too complicated, so I quickly implemented this behaviour to see what it feels/looks like. Here's the video: Bildschirmaufzeichnung vom 2023-12-23, 18-34-38.webm

---

EDIT: To improve the accuracy when using the app like this, it would also be possible to remove the spacing between the bars: Bildschirmaufzeichnung vom 2023-12-23, 18-43-37.webm

[kra-mo]

I think this works well. While not immediately intuitive, it does make sense once you start scrubbing which is where it would be relevant anyway.

The version without spacing looks off though, I would still keep them.

I do also think white/gray still would look better here instead of blue/white.

[vixalien]

Admittedly, the best solution will require removing the scale. At this point, I have no consensus on what to implement from a solid design so I'll wait.

[BlobCodes]

The version without spacing looks off though, I would still keep them.

It would also be possible to start the waveform progress bar at 10% screen width and end at 90% screen width (or something like that). The scale below also doesn't start at the leftmost pixel.

EDIT: Oh you meant the spacing between the bars. I somehow thought you meant the margin at the left/right of the window. (I should stop writing these comments at night)

I do also think white/gray still would look better here instead of blue/white.

I personally like the blue/gray version more, but that's personal preference. I primarily chose the blue/gray version to have more contrast with the third color. (In the video there's a dimmed blue color representing the difference between the song position and the selected position)