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 799394 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: foo_wave_seekbar

Reply #2125
I've also observed this GPU drain and have not really found any way to mitigate it if you still want smooth painting.
The choices available as a child window is very limited and the only way to reduce it is indeed to draw less often.

The GDI mode in foo_wave_seekbar has a much lower update rate than the other two frontends. foo_wave_minibar doesn't have any control at all, as it was made to not be complicated. The difference between GDI and minibar is strange, as they're pretty much the same kind of painting logic.

It wouldn't surprise me if this is something that newer Windows 10 builds introduced too, considering that I've never had any trouble in the past with either component.

As for resolving this, I've got no clue. Drawing rapidly as a child window in foobar2000 is a right mess and you have to either be wasteful or careful to not starve the message pump. It's one of the reasons why I never bothered to make any dockable visualisations as the perf just isn't there.

Edit: I wonder how to benchmark this... run a stable game on the side and see how much mud it sucks?
Stay sane, exile.

Re: foo_wave_seekbar

Reply #2126
I've had this stuttering ever since Windows 8 days, and it seems to only happen with multiple monitors both running at different refresh rates. Running a game in windowed mode with framerate capped at refreshrate, or moving a window around is how I usually spot the stuttering.

I personally don't care how smoothly the seekbar moves, most of the time I have foobar open it's open in my other screen and without any focus on it. The slow update rate of ~5Hz or so should be enough to mitigate the issue at least for me.

Re: foo_wave_seekbar

Reply #2127
GoaLitiuM, if you wish to give a shot to my modfied version of Minibar its latest version has configurable frame rate and it stops screen updates when playback is paused or stopped.

Re: foo_wave_seekbar

Reply #2128
GoaLitiuM, if you wish to give a shot to my modfied version of Minibar its latest version has configurable frame rate and it stops screen updates when playback is paused or stopped.
This is much better! How fast did it used to update before the change? It stutters much less now than before (about the same as foo_wave_seekbar in GDI mode), but there doesn't seem to be any difference with 5fps vs 60fps for the stuttering. Both plugins still stutter when the playback is paused though, and sometimes the minibar doesn't refresh the view when transitioning from paused to stopped state.

Re: foo_wave_seekbar

Reply #2129
60 fps has been the default. The update logic has been a bit different from zao's original version but I don't think it should affect stuttering.

Do you have some visualizations or anything else weird in the UI? Once you hit stop or pause the component draws a few frames and then stops the refresh timer. Minibar at that point won't consume any CPU or GPU resources.
 
I replicated the state update bug, btw. I'll get it fixed but perhaps not today. Movie night.

Edit: fixed. Updated versions available.

 

Re: foo_wave_seekbar

Reply #2130
Dear Case, I regret to inform you that AAC LC files are not processed, i.e. viewport for waveform is totally filled with one (grey) colour.
Could you be so kind to fix it?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_wave_seekbar

Reply #2131
@Kraeved Do you have an sample file that fails to scan, and what kind of output do you get in the Console when this happens?
Stay sane, exile.

Re: foo_wave_seekbar

Reply #2132
@Kraeved - problem with raw AAC files is that they don't report length and don't support seeking (Peter's decision). Here's a test version that shows the waveform for such files anyway. It doesn't show any progress though. Would showing progress for unseekable files still make sense or would blank seekbar be preferred?

Edit: attachment removed.

Re: foo_wave_seekbar

Reply #2133
Zao, here goes the sample file as you requested. Story behind it as follows: I downloaded a videoclip via youtube-dl, then extracted its AAC LC encoded sound stream via ffmpeg to cut the visual weight off. No doubt I would prefer to avoid further transcoding to other lossy formats if possible.

Case, thank you for a quick fix, it surely soothes the tormented soul a bit, at least it enables me to see what happens, albeit not to control. Thing is I keep native seekbar hidden and use your waveform element to seek playable files instead. Thus, the inability to seek (even non-accurately via imaginable checkbox in Advanced settings) infuriates me (and others) as I feel paralyzed (remember Stephen Hawking?), given that AAC is more widespread than, for example, MPC. Oh, Peter…

It seems the best bet so far is to put AAC into M4A container like this ffmpeg -i file.aac -acodec copy file.m4a
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_wave_seekbar

Reply #2134
I was going to suggest muxing it into a container based on your email, but it seems that you have already suggested it yourself now. :)

The reason the seekbar originally filters out tracks that doesn't support seek is that it's a good filter against weirdo formats that probably won't work anyway, and ones that tend to not advertise a correct length.

With some effort, or worst case, a two-pass analysis, they _could_ be processed to get a waveform but as you've observed, they still wouldn't seek right.
Stay sane, exile.

Re: foo_wave_seekbar

Reply #2135
@Kraeved : the restrictions are just political push to get people to use proper container with the files. The ADTS AAC stream is similar to MP3 and requires parsing the bitstream to build seektable and extract track length. It was supported in foobar2000 v0.8 days and I have tried to get him to restore it, but without success.

The recommended way to proceed is to convert the files to MP4. The container allows instant seeking without building seektables manually and it allows using proper tagging. The ffmpeg method you used is lossless.

Another option with foobar2000 v1.4 is to use FFmpeg Decoder Wrapper component and add *.AAC format to be handled by it. You can enable APEv2 tagging for the files without harming their use at least in most PC programs. This method requires setting the FFmpeg decoder component to be preferred over the built-in decoders in foobar2000.

But I'm still unsure what to do with Minibar (mod) component. Supporting files without length info properly requires changing the database format so I could store the length there without need to decode the file again each time. Another option is to do as the test version, possibly with added progress display. Or do as the original design was intented to work and show nothing but blank.

Re: foo_wave_seekbar

Reply #2136
Spoiler (click to show/hide)

Case, I believe the waveform should be shown if there is any sound bits within the file. Otherwise user would feel lost, because something is definitely pouring from the headphones and the status bar shows the elapsed time. A small question sign inside a faded circle somewhere in the right corner of the waveform with a tooltip explaining the inability to seek would complete the picture. Also, adding an option whether or not to “process formats without duration” might mitigate your worries about lengthy files, right?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_wave_seekbar

Reply #2137
I'll see how to improve the situation after work. I also had a crazy idea to allow seeking in unseekable local files. I can inject a DSP that brute-force decodes the file to the point user wants to seek to and then remove the DSP from the chain.

Re: foo_wave_seekbar

Reply #2138
@Case : Sounds like idea for foo_dsp_hacks. Reminds of similar plug fo UI ;-) . Nasty :-)
@Kraeved : I also wanted things to "work as I wish without changing files" to mitigate workload if I accidentally get big bunch of "problematic files". But you can see even in this thread history, that I changed my mind. I have had large collection of mvids in various containers (avi, mpg, etc.), from which I wanted to play audio in foobar. To mitigate certain problems I remuxed its whole to mkv containers using batch processing. Quick and easy process. Where remux was impossible (due to errors) I just configured foobar for certain file extensions to be decoded via foo_input_ffmpeg. No insisting on "avi must work" or "mpg/mpeg/m2v must work". We should use solutions that exist instead on keeping stuck in problematic situation. Especially if we have knowledge (about lossless remuxing, existing plugins, etc.).

Re: foo_wave_seekbar

Reply #2139
@Kraeved : new version of Minibar mod is up. It now shows the waveform for files without length and allows seeking in them.

Re: foo_wave_seekbar

Reply #2140
Case, it seems a dirty workaround has its price as I faced a shutdown of Foobar2000 after trying to open CUE sheet pointing to non-existent files.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_wave_seekbar

Reply #2141
Thanks for reporting. Fixed.

Re: foo_wave_seekbar

Reply #2142
Case, by the way, why the waveform of a lengthy file is still generated without regard to my order to stop the playback?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_wave_seekbar

Reply #2143
Stopping playback doesn't mean you won't play the file again. If the file is in your library the final scan will be stored in the database and the next time you come to the file the waveform is shown instantly. If the file is not in the library the waveform will still be cached for as long as the player is running. It works as designed.

I have realized scanning the waveforms can be slow on slow machines. For example on my test emulated Pentium 2 one has to wait quite long to see results. I may add an option to abort background scans that take longer than configured time.

Re: foo_wave_seekbar

Reply #2144
may i suggest adding the ability to scroll over the seekbar to jump back/forth within the track, like in the original wave seekbar?

Re: foo_wave_seekbar

Reply #2145
Wheel seeking is enabled in the just released 1.0.11 version. By default one notch worth of wheeling seeks by 10 seconds. Configuration allows selecting the duration or changing the seek to use percentage of track length instead of static seconds.

Re: foo_wave_seekbar

Reply #2146
Hi Case, I switched over to Waveform Minibar.  The edges are a lot harder whereas with the original waveform seekbar, they were quite a bit softer; any way to get a little blending/blurring around the edges?

Re: foo_wave_seekbar

Reply #2147
Blurring like in the default DX9 waveform can't be done. You can get somewhat softer look by changing the colors to have less contrast and adjust the fill color closer to the background color. I'm sure you'll get used to the different looks.

Re: foo_wave_seekbar

Reply #2148
Wheel seeking is enabled in the just released 1.0.11 version
Can it be disabled, like in the original?
In theory, there is no difference between theory and practice. In practice there is.

Re: foo_wave_seekbar

Reply #2149
Yes @GeSomeone - just set the seek amount to zero.