Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_wave_seekbar (Read 806852 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_wave_seekbar

Reply #1825 –
Hi Zao,

thanks for providing the opportunity to openly commit oneself to be insane.
Indeed the plugin is quite a lot snappier now, very nice!!
  • The option to "incremental update waveforms being scanned" appears to be not working in this release, though. I hope it is coming back?
  • Can you please explain what the option "percentage of base display rate to display at (1-400%)" does? Does it affect the refresh rate of the wave graph?

foo_wave_seekbar

Reply #1826 –
Heh, the phrasing on that percentage parameter is forever confusing.

The frontends have a particular interval between attempts to redraw itself. It's 50ms for GDI, 25ms for Direct2D, and 10ms for Direct3D9.
Expressed in Hertz, this would be an update rate of 20Hz, 40Hz and 100Hz, respectively.

The parameter adjusts this rate. A value of 200% will double the update rate, resulting in a twice as smooth (and costly) display.

As for incremental scans, it's still very rough and half-functioning. Under the covers, it always scans the track incrementally if the flag is on, but the propagation of this result to the frontend is not fully wired up. I need to finish that propagation, and ensure that I do less work in generating an incremental result if incremental results are not desired.

Be happy you're not trying 0.2.45.1, which had 20s UI blocking delays on track change when incremental scans were enabled.
Stay sane, exile.

foo_wave_seekbar

Reply #1827 –
Hi Zao,
I have a question if some functionality would be possible in your component.
Let's assume that foobar is running but it is not playing any track - just idling. When you move cursor through the tracks on playlist and you have album art viewer turned on, pictures are changing automatically.
Is this possible that for files that are already scanned and have their signatures, also signatures would be automatically changed similarly to pictures in album art viewer? But only when playback is stopped (and not when it is just paused).
I will not call it feature request. Just a casual proposition that might be implemented if anyone will find it interesting. First of all, the question is if this can be done without turning current code upside down. If too many changes will be required to current structure, then just let it go and forget that I ever asked about it

foo_wave_seekbar

Reply #1828 –
Indeed.

I've pondered how to make something like what you propose before, as evidenced by the ancient entry in the bug tracker for such a feature.

It's slightly less impossible with the changes in the scanning backend as present in the test builds of 0.2.45.3 (that's a mouthful, eh?), as I've changed how results from scans are handed back to the requesting party.

What remains to be done is wiring up code to make requests based on selection changes, and set up the ability to shadow the currently showing waveform.

The open questions are things like how to handle multiple selections, if at all. Show it take priority while playing, while paused, or only while stopped. Should clicks on the track start playing it, seek in the track?

Some of those belong in settings. Some of those should not make it in. Some should be implemented. Time will tell if I get around to think it all out.
Stay sane, exile.

foo_wave_seekbar

Reply #1829 –
There's a bug when using GDI for the frontend: playing very short files on repeat causes full CPU load and Foobar freezes...

For example a file like this (but it doesn't have to be that short).

foo_wave_seekbar

Reply #1830 –
Exciting. I'll see if I can get a build up again after my Windows 10 decided to self-destruct.
Stay sane, exile.

foo_wave_seekbar

Reply #1831 –
Quote from: Brand on
There's a bug when using GDI for the frontend: playing very short files on repeat causes full CPU load and Foobar freezes...

For example a file like this (but it doesn't have to be that short).

I cannot reproduce this problem with 0.2.45 or 0.2.45.4, with neither GDI nor D3D.

What version are you on of foobar2000 and my component?

Edit: Missed the repeat. Now that looks glorious.
Stay sane, exile.

foo_wave_seekbar

Reply #1832 –
crash on startup
Quote
Failed to load DLL: foo_wave_seekbar.dll
Reason: Unknown error code (3221225501)

v.0.2.45 from component page
WinXP SP3 Athlon XP (non-sse2)
QC, QA

foo_wave_seekbar

Reply #1833 –
Quote from: askold on
crash on startup
Quote
Failed to load DLL: foo_wave_seekbar.dll
Reason: Unknown error code (3221225501)

v.0.2.45 from component page
WinXP SP3 Athlon XP (non-sse2)

The slightly experimental 0.2.45.4 is built with VS2010 and as such doesn't default to assuming SSE2 presence and may work on your machine..

Amusingly enough, I just used SSE2 explicitly in my development builds to accelerate the GDI frontend. These days, you kind of have to assume _some_ kind of baseline system. I can't wait for the day when 64-bit is mandatory, as I could rely on SSE2 then.
Stay sane, exile.

foo_wave_seekbar

Reply #1834 –
Quote from: Brand on
There's a bug when using GDI for the frontend: playing very short files on repeat causes full CPU load and Foobar freezes...

What is your actual use case that encounters this problem?
Are you repeatedly playing the same file, or do you for some obscure reason have playlists full of miniscule tracks, abusing foobar2000 as an ad-hoc tracker?

This is a corner case that incurs a ton of complexity to resolve properly, as I've designed around the use case of reasonable-length tracks. Heck, your 339 sample track will have serious artifacts due to the 2048-bucket approach of the component.
Stay sane, exile.

foo_wave_seekbar

Reply #1835 –
Quote
The slightly experimental 0.2.45.4 is built with VS2010 and as such doesn't default to assuming SSE2 presence and may work on your machine


thanks, man - it works
QC, QA

foo_wave_seekbar

Reply #1836 –
Waveform Seekbar 0.2.45

GDI frontend has small visual glitch:

-> start playback of a new track


Result: At the left a vertical blue line remains which goes away when resizing the scrollbar (foobar window). Can be seen best with "Shade played" disabled.



Feature request: Can we have "Shade played" for AudioCD playback in GDI mode? In Direct3D mode it's working.


Thank you!

foo_wave_seekbar

Reply #1837 –
Quote from: Zao on
Quote from: Brand on
There's a bug when using GDI for the frontend: playing very short files on repeat causes full CPU load and Foobar freezes...

What is your actual use case that encounters this problem?

I encountered it when opening some drum samples and the playback happened to be on repeat. As I said, it doesn't need to be an extremely short sound, like the one I linked, but maybe even something around 100ms...

I switched to D3D and it's fine. So no big deal for me and it shouldn't affect regular music, just putting it out there.


(Sorry for late reply, didn't see your post sooner.)

foo_wave_seekbar

Reply #1838 –
Brand: That's great. I should still have some rate limiting to mitigate such runaway trackstarts, but it's nice to see that it's not an legitimate workflow that broke.

Dandruff: I think that I've seen that problem reported before, not quite sure yet if it's a stray position indicator or an offset in update region calcs, if I have those. As for the CDDA thing, never seen that, probably because I don't have any optical drives anymore.

I filed issues for those two things so I can more reliably forget about them.
Stay sane, exile.

foo_wave_seekbar

Reply #1839 –
Cool,  thanks!

foo_wave_seekbar

Reply #1840 –
Another small request: Could you add normalized waveform display as default?

foo_wave_seekbar

Reply #1841 –
The problem with having normalize-to-fit is that without any form of tickmarks or scale indicators, it defeats one of the core purposes of the component, seeing if tracks are quiet or above fullscale.

Not really sure how replaygain compensation fits into things either, I don't remember if that's in the default effect or not.
Stay sane, exile.

foo_wave_seekbar

Reply #1842 –
Quote from: Zao on
The problem with having normalize-to-fit is that without any form of tickmarks or scale indicators, it defeats one of the core purposes of the component, seeing if tracks are quiet or above fullscale.


Ok, but you could make this optional (checkbox in preferences).


Quote from: Zao on
Not really sure how replaygain compensation fits into things either, I don't remember if that's in the default effect or not.


It's not I think. But that's something I wouldn't need personally. I just like to see all the waveforms normalized to 0dBFS. To see if they are quiet or loud I can use my ears or a levelmeter.

foo_wave_seekbar

Reply #1843 –
I'd certainly welcome a fit-to-window toggle as well.

My personal usage is to jump between certain (silent vs loud) parts of the current song. I'm not interested in how tracks wage against each other in loudness on an absolute/static scale. Only to gain a quick overview on how the rest of the song looks like relative to the part I'm currently at. Is there a big action section at 3/4 of the song that is otherwise close to silent? I want to see that. If the song is unusually quiet (and consistently so) with the peaks barely spiking out, this actually becomes hard to see as of right now. This is a rare and specific occurrence, just thought might as well mention it.

foo_wave_seekbar

Reply #1844 –
But this would need some type of "compression". Personally I don't need/want this. I just want to see the highest peak of the track at the border of the window (scaled, not compressed).

foo_wave_seekbar

Reply #1845 –
I'm talking about simple scaling as well. Maybe my rambling at the end implied otherwise, that wasn't my intention.

foo_wave_seekbar

Reply #1846 –
I'm starting to remember the horrors of trying to implement a robust and useful normalization in the past.

There are two core problems.

What does one do with waveforms that have a DC bias? Should they scale to absolute magnitude, or so that lowest and highest peaks touch the edge.

A naive scale where a single sample spike is all it takes to push the scale out isn't overly pleasing. How many samples are needed to be considered significant, and how on earth do you compute that reliably?

Experiments with computing bounds from mipmaps in the D3D frontend show no conclusive evidence for any flavor being better than another, so I put it on the shelf forever.
Stay sane, exile.

foo_wave_seekbar

Reply #1847 –
With a lot of guessing and tinkering, probably. My initial try would be (obviously numbers subject to change):

1) Find highest peak (A0)
2) Find peaks of similar magnitude to A0 within a 10% margin (A1, A2, A3...)
3) Check if step 2 nets at least 3 samples (A1, A2, A3). If not, repeat steps 1 and 2 with A0 = second highest peak, third highest peak, etc. until a sufficient sample group is found.
4) Scale the waveform to the average of A0,A1,A2,A3.

Note that I don't know how the data collection for the waveforms work thus what kind of data is available to work on, so my thought process could be completely wrong. This primitive normalization idea might as well crash and burn the moment you feed it real data, too. I'd need to mess around a lot to find an algorithm that works acceptable enough. Is using ReplayGain values out of question? Would it make any sense for what we are trying to accomplish?

I'd still be curious to test myself how the waveforms look like if you just scale it to the single highest peak and nothing else, by the way.

foo_wave_seekbar

Reply #1848 –
Analysis takes the waveform, splits it evenly into 2048 segments and for each segments, produces the minimum and maximum value, as well as RMS measure of whatever RMS measures.

The Direct3D frontend has all the information you would ever need available in shaders, as it has both replaygain factors and numeric min/max values of the waveform, I believe. This leads to a problem with the imagined "normalize display" option, as that would either have to mutate the data (affecting all effects in ways that may not expect it) or set an additional flag (which no effects knows how to interpret).

Personally, I consider this generation of the component a bit of an evolutionary dead end that only really exists as a courtesy to XP users, and because I have not made a proper replacement yet without all the freely programmable headaches.
Stay sane, exile.

foo_wave_seekbar

Reply #1849 –
Quote from: Zao on
Personally, I consider this generation of the component a bit of an evolutionary dead end that only really exists as a courtesy to XP users, and because I have not made a proper replacement yet without all the freely programmable headaches.

Having said that why not declare the current release as the final version of the v2.x branch including WinXP support? Move ahead to a v3.xx branch leaving behind any roadblocks and bottlenecks that are hindering your progress (and probably your enjoyment) in developing the plugin further. Meanwhile WinXP is an fairly old OS, system updates and support by the developer has been discontinued since quite some time. With the release of Windows 10 being very close, there are plans to make WinXP users an attractive upgrade offer.