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

foo_wave_seekbar

Reply #1125
That effect goes from background color at the very edge, shooting through the text color a particular distance from the outline, and goes past by that delta, in this case ending up with white saturation.

The colors used is from one of the built-in themes:
Text: R 244, G 126, B 70
Background: R 33, G 35, B 31
Selection: R 171, G 163, B 154
Highlight: R 175, G 171, B 143

There might be some effect source in earlier threads, if whatever one is built-in nowadays doesn't reproduce it.
Stay sane, exile.

foo_wave_seekbar

Reply #1126
That effect goes from background color at the very edge, shooting through the text color a particular distance from the outline, and goes past by that delta, in this case ending up with white saturation.

The colors used is from one of the built-in themes:
Text: R 244, G 126, B 70
Background: R 33, G 35, B 31
Selection: R 171, G 163, B 154
Highlight: R 175, G 171, B 143

There might be some effect source in earlier threads, if whatever one is built-in nowadays doesn't reproduce it.

I don't have a text color option, but I have a foreground colour option. Anyway copying the values (adding the ones from thext ot the foreground option) I get something similar, but still quite different.

foo_wave_seekbar

Reply #1127
Right, foreground.

You could either make that colour a bit brighter, or add some factor to the responsible lerp in the source - the end effect should be reasonably similiar. The differences are probably mostly because your waveform is lower amplitude than the one in my shot.
Stay sane, exile.

foo_wave_seekbar

Reply #1128
Right, foreground.

You could either make that colour a bit brighter, or add some factor to the responsible lerp in the source - the end effect should be reasonably similiar. The differences are probably mostly because your waveform is lower amplitude than the one in my shot.

Oh, ok.

foo_wave_seekbar

Reply #1129
You're right that wasn't possible, here's an updated version which sets the background colour to the highlight colour if "shade played" is disabled. http://pastebin.com/q6qLaQ18

I'm using a lightly modified version of this script (mainly I've just turned the inner form back on, iirc), but I'd like to replace the inner RMS waveform with just a straight centerline the same color as the background. I thought it'd be simple, just unplug something in RMSfactor, but this language is pretty opaque to me. Could someone help me out, please?

foo_wave_seekbar

Reply #1130
Can anyone tell me which part of the default settings to modify so that it takes ReplayGain into consideration?

foo_wave_seekbar

Reply #1131
This is fantastic, thanks. It is working for me in Direct3D 9.0c mode with Intel 965 Integrated Graphics chip. If this were incorporated into Foobar2000 as a standard base component I think it would increase the popularity of Foobar2000.

I have it set to just display the "Front right" channel - why spend extra computation cycles on 'downmixing display to mono' - for most music applications just showing one channel is adequate and should be the default.

Also - when I have it set to "Store analysed tracks in mono" it seems to be using much more CPU and taking much more time. Is it spending computation time on merging the Left+Right sound tracks? Is there any way I can set it to just store "Front right" and just display "Front right" -- not do any heavy left-right merging operations (I just need simple visual to seek around within DJ sets to find song boundaries).

foo_wave_seekbar

Reply #1132
The waveform is very nice and pretty - but it is taking quite a bit of CPU to create - for a 1 hour music set it takes around 20 seconds of 99% processor usage using two processors of a 2.2 Ghz Core 2 Duo Intel Machine.

Is there any way to have a less pretty, less-detailed, lower frequency, lower sample-rate version that is snappy and quick to create? Something like Soundcloud does. I feel the seekbar signature shouldn't take more than 1 second of CPU time to create. I feel the CPU does not need to sample so heavily to create such a detailed bar that is just going to be displayed in a small section of the screen anyways. Sampling at something like 5hz (5 times per second) should be way more than enough? What is the current sampling rate that is being used to build the seekbar signature?

Better yet - the sampling rate can reduce as the length of the track increases past certain thresholds. So if it is a 1 hour music set that is being indexed for seekbar signature - that is 3600 seconds to be displayed across the horizontal resolution of my screen. My screen only has 1600 pixels horizontally across anyways. So for something longer than 20 minutes - the sampling frequency can even be 1hz. 3600 bars to be displayed across 1600 pixels on an LCD screen sounds right for a 1 hr music set.

Also, I feel this could be done without requiring the DirectX end-user runtime which would open it up to much higher compatability.
http://gareus.org/wiki/sndfile-waveform
https://github.com/beschulz/wav2png
http://www.schillmania.com/projects/soundmanager2/


foo_wave_seekbar

Reply #1134
Additionally, I'm a bit curious as to if there are any surviving XP users around. It's getting more and more bothersome to target XP and well as Direct3D 9. It would be very nice to know if it's finally possible to move on, as I do not have any machines running XP anymore to test the corner cases of the completely pants-on-head stupid device reset model that D3D9 has. Upstream compiler support for XP, D3DX and D3D9 is gone, and the OS itself will be properly EoS:ed Real Soon Now.


*Raises hand*. Lots of surviving XP users will remain - especially for music playing, lots of people (such as myself) use old laptops for music playing servers connected to speakers. You'll be glad to hear that foo_wave_seekbar is working perfectly for me with Direct3D 9.0c on Windows XP on a Thinkpad T61 with Intel 965 Integrated Graphics.

The reason is that there is simply no reason to upgrade. Only when I get an SSD will I upgrade to Win7 for the TRIM support. XP is better suited to old laptops and uses less memory and hard disk space than Win7.

Thanks.

foo_wave_seekbar

Reply #1135
This is fantastic, thanks. It is working for me in Direct3D 9.0c mode with Intel 965 Integrated Graphics chip. If this were incorporated into Foobar2000 as a standard base component I think it would increase the popularity of Foobar2000.

Nothing stops anyone from recommending it on "top 10 components"-style lists, which probably gets better exposure than some strange unknown bundled UI element that no-one knows to look for.

I have it set to just display the "Front right" channel - why spend extra computation cycles on 'downmixing display to mono' - for most music applications just showing one channel is adequate and should be the default.

Also - when I have it set to "Store analysed tracks in mono" it seems to be using much more CPU and taking much more time. Is it spending computation time on merging the Left+Right sound tracks? Is there any way I can set it to just store "Front right" and just display "Front right" -- not do any heavy left-right merging operations (I just need simple visual to seek around within DJ sets to find song boundaries).

The mixdown is done after the analysis, and thus has no real impact whatsoever on the speed as it acts on at most a few thousand data points. Similarly, it shouldn't have any noticeable cost when preparing a waveform for display. It's just 2048*[1-8] averages, after all.

I dislike the notion of hiding information in a default setting. If you have needs to change it, it's mutable for a reason.

The waveform is very nice and pretty - but it is taking quite a bit of CPU to create - for a 1 hour music set it takes around 20 seconds of 99% processor usage using two processors of a 2.2 Ghz Core 2 Duo Intel Machine.

Is there any way to have a less pretty, less-detailed, lower frequency, lower sample-rate version that is snappy and quick to create? Something like Soundcloud does. I feel the seekbar signature shouldn't take more than 1 second of CPU time to create. I feel the CPU does not need to sample so heavily to create such a detailed bar that is just going to be displayed in a small section of the screen anyways. Sampling at something like 5hz (5 times per second) should be way more than enough? What is the current sampling rate that is being used to build the seekbar signature?

Assuming around 500x realtime decoding, an hour of audio takes around ten seconds to decode, let alone analyse.

Better yet - the sampling rate can reduce as the length of the track increases past certain thresholds. So if it is a 1 hour music set that is being indexed for seekbar signature - that is 3600 seconds to be displayed across the horizontal resolution of my screen. My screen only has 1600 pixels horizontally across anyways. So for something longer than 20 minutes - the sampling frequency can even be 1hz. 3600 bars to be displayed across 1600 pixels on an LCD screen sounds right for a 1 hr music set.

As linked, the analysis gathers audio linearly into 2k buckets per channel, resolving results as it goes.
If I were to seek and look at subparts of songs, it'd likely miss out on interesting features in the waveform, and would have some severe decoder seek costs.
Yes, the analysis might be "slow", but it's fast enough for the majority.

Also, I feel this could be done without requiring the DirectX end-user runtime which would open it up to much higher compatability.
http://gareus.org/wiki/sndfile-waveform
https://github.com/beschulz/wav2png
http://www.schillmania.com/projects/soundmanager2/

First two are licensed under the GPL and are thus nothing I can't even look at.

As for the DirectX redist, that is solely for the use of the effect compiler and/or d3d_compiler. No matter how I spin it, if I want to compile effects, I need it present. If you use the D2D or GDI frontends, you don't need it.

I could swear I saw a mention of having to right-click, but I guess it was edited. It automagically scans (if enabled) the playing track and the next one to play, ahead of time.
Stay sane, exile.

foo_wave_seekbar

Reply #1136
I've done some ad-hoc benchmarking of a typical MP3 set, and I get around 8 seconds for a 1h20m track. Out of that, at most 2 seconds is from my code, the rest is in decoding and data shoveling.

In order to achieve any significant improvements, I'd have to decode less audio. This means that I'd have to seek, which is not remotely free. If we decide to analyze only some lumps of the track, we need to consider the implications.
Given a 1h track, we've got buckets of 1.75 seconds for each sample in the result. If we only decode half of this interval, we'll completely miss any energy and peak content of the other half. Lowering the scanned:unscanned ratio would possibly improve speed, but cause greater blindness.

In the end, the executive summary is: if you want higher speeds, use faster hardware/formats. Otherwise, do your scanning ahead-of-time or during other downtime. The analysis process is idle-priority, so it shouldn't really affect your normal operation in any way.
Stay sane, exile.

foo_wave_seekbar

Reply #1137
You're right that wasn't possible, here's an updated version which sets the background colour to the highlight colour if "shade played" is disabled. http://pastebin.com/q6qLaQ18

I'm using a lightly modified version of this script (mainly I've just turned the inner form back on, iirc), but I'd like to replace the inner RMS waveform with just a straight centerline the same color as the background. I thought it'd be simple, just unplug something in RMSfactor, but this language is pretty opaque to me. Could someone help me out, please?

Thats not a script, its a pixel shader. Get your facts straight.

foo_wave_seekbar

Reply #1138
This means that I'd have to seek, which is not remotely free. If we decide to analyze only some lumps of the track, we need to consider the implications.


I did some quick speed tests, and seeking has a significant cost. For the Ogg Vorbis track I tried, decoding the whole track is equivalent in time to decoding 40% of the song with 2048 seeks.
The cutoff fraction for MP3 was somewhere around 85%, FLAC 65%.

All in all, the accuracy penalty isn't worth the miniscule improvement in analysis time.
Stay sane, exile.

foo_wave_seekbar

Reply #1139
Thanks. One more request. I am trying to save hard drive seeks by not scanning every single thing opened (some times I do not need the seekbar info, or am just opening something for a few seconds and then closing it).

I have unchecked "Analyze tracks not in the media library" - and the automatic signature building for everything has stopped (I don't use the Foobar2000 library anyways). But now it would be nice to be able to manually build some signatures via Right Click > Utilities > Extract Seekbar Signature. It seems that "Extract Seekbar Signature" does not work for tracks not in the media library when "Analyze tracks not in the media library" is unchecked. It would be nice if "Extract Seekbar Signature" would override "Analyze tracks not in the media library" so that there is an ability to manually choose which songs the signature will get built for and which for not. Or an option to turn off "automatic signature building" at times when the user wants to save hard disk activity -- and allow manual only operation via a button on the toolbar (the "Extract Seekbar Signature" menu item can already be added to the toolbar -- but it is missing an icon).

foo_wave_seekbar

Reply #1140
I figured another thing that was greatly slowing down signature creation. I had number of threads set to 2 and observed the filesystem activity with Sysinternals Process Monitor. It starts immediately creating the currently playing song in the 1st thread and the next song in the playlist in the second thread. So you have two threads which are requesting data from the hard drive at the same time. Process Monitor showed reading between File1 and File2 over and over again, switching rapidly back and forth - asking the filesystem to give it streams of two files at two different locations at the same time was causing a lot of disk thrashing.

I set the number of threads to 1 and now it is only reading one file at a time which has greatly reduced disk thrashing. Sequential read access on a single file is much faster on a spinning hard drive than random reads between two files at the same time. A huge bottleneck also is probably the rate at which the plugin can load the entire song into RAM for analysis.

Based on this - I would recommend that the # of threads be always set to 1. Parallel threads should only be run when working with in-memory objects.

Screenshot of Process Monitor with # of threads = 2:

foo_wave_seekbar

Reply #1141
The default cap for number of threads (3) is the cutoff point where a typical machine doesn't gain more from adding threads.

If your harddrives and/or file buffering characteristics are horrible enough to warrant crippling it to one thread, do so - it's configurable for a reason. What OS are you on that exhibits such horrible prediction?

I've considered fully buffering files, but that's either pointless (for small files) or unfeasible (for larger files or archives). Any solution with serial disk I/O will be pretty much equivalent to crippling yourself to a single thread anyway.
Stay sane, exile.

foo_wave_seekbar

Reply #1142
If your harddrives and/or file buffering characteristics are horrible enough to warrant crippling it to one thread, do so - it's configurable for a reason.

In my case - each of my "songs" are 1hr+ 120MB+ files so no filesystem cache is going to load two of these files fully into memory. For people using Foobar2000 with 5 min songs it is probably fine for them. Running with 1 thread with large 1hr songs fixes the problem and results in nearly sequential disk access behavior and the "thrashing" observed earlier from constantly blinking hard drive light and observed noise coming from hard disk head movement is now gone.

foo_wave_seekbar

Reply #1143
Can I get an answer regarding this?

Can anyone tell me which part of the default settings to modify so that it takes ReplayGain into consideration?

foo_wave_seekbar

Reply #1144
Can anyone tell me which part of the default settings to modify so that it takes ReplayGain into consideration?

Consideration for what area of the component?
The analysis process won't take RG into consideration in any way.
The display doesn't take RG into consideration unless you use the Direct3D frontend, where the RG parameters are available in the four-component REPLAYGAIN semantic.

Code: [Select]
float4 replayGain      : REPLAYGAIN; // album gain, track gain, album peak, track peak
Stay sane, exile.

foo_wave_seekbar

Reply #1145
Sorry for not being specific enough—I was talking about the display. I found some front-end setting that DOES take it into consideration while displaying, but the rest of it looks ugly. Guess I'll try to modify the default one myself...

foo_wave_seekbar

Reply #1146
My vote would still be for an option in Preferences to "Disable automatic scanning from playlist entries".

I like to load my songs into RAMDisk via the RAMDisk plugin. So I first load the song from Explorer - it loads in Foobar - then I click on "Send to RamDisk". then I click on "Send to Playlist" in the RamDisk window to send the Ramdisk file to the Playlist. This results in foo_wave_seekbar first scanning the file on the hard disk - and then again for the file on the RamDisk. I only want it to scan files that I load from my Ramdisk.

So another request (or another way of doing this) would be that there would be a path filter - "Exclude paths in pathexclude.ini". I could specify the paths from which I want foo_wave_seekbar to not scan. If I wanted to turn off automatic scanning all-together (and run in manual-only mode) - then I could specify "*" in pathexclude.ini. Otherwise I could specify specific directories from which foo_wave_seekbar should not engage in automatic signature creation.

foo_wave_seekbar

Reply #1147
My vote would still be for an option in Preferences to "Disable automatic scanning from playlist entries".

Have you tried unchecking "Analyse tracks not in the media library" under "Preferences -> Advanced -> Tools -> Waveform seekbar" ?

foo_wave_seekbar

Reply #1148
That fails if he wants his HDD to be indexed by the media library but not scanned by the seekbar.

The "don't scan stuff not in library" setting is from a day where everyone and their mother wanted blacklists and whitelists of what to scan where. I implemented it as a trivial stopgap measure, as I didn't want to make the painful UI needed to customize location lists.

In general, the more UI a feature needs, the less I'm motivated to work on it.
Stay sane, exile.

foo_wave_seekbar

Reply #1149
My vote would still be for an option in Preferences to "Disable automatic scanning from playlist entries".

Have you tried unchecking "Analyse tracks not in the media library" under "Preferences -> Advanced -> Tools -> Waveform seekbar" ?

I´ve just seen from early posts that you already knew this option.
I tried foo_ramdisk and found that it is mapped at the application level and can´t be added to Media Library so my suggestion wouldn´t work anyway.

The only other option I can think of is the use of a regular RAM disk.

The "don't scan stuff not in library" setting is from a day where everyone and their mother wanted blacklists and whitelists of what to scan where. I implemented it as a trivial stopgap measure, as I didn't want to make the painful UI needed to customize location lists.

Fair enough