Hydrogenaudio Knowledgebase - User contributions [en]

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2020-05-21T18:45:13Z

Chronial: New Release

{{Foobar Component Infobox
| name = Chronial's Coverflow
| screenshot = [[Image:foo_chronflow.jpg|256px]]
| caption = Chronial's Coverflow
| module_name = foo_chronflow
| maintainer = Christian Fersch [Chronial]
| stable_release = 0.5.2
| stable_release_date = 2020-05-21
| foobar2000_version = 1.3.3
| foobar2000_ui_module = Default UI, Columns UI
| use = UI
| license = GPL
| discussion_thread = [http://hydrogenaud.io/index.php/topic,108450.0.html Hydrogenaudio Forums]
}}

'''Chronial's Coverflow''' is a coverflow plugin for foobar2000. This plugin provides a UI panel that displays a 3d rendering of the albums in your media library.

== Preferences ==
=== Cover Display tab ===


[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

=== Performance tab ===
[[Image:foo_chronflow preferences.png|thumb|300px|Chronflow Preferences page showing the "Performance" tab.]]
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the renderer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

==== Rendering Quality ====
These Settings influence the quality of the generated image.

{{panel|'''Note:''' Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar2000).|color=yellow}}

==== Texture Cache ====
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

==== VSync ====
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 

==== Benchmarking ====
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

==External links==
* [http://github.com/Chronial/foo_chronflow Official website]
* {{ha|https://hydrogenaud.io/index.php/topic,108450.0.html}}

{{DISPLAYTITLE:foobar2000:Components/Chronial's Coverflow (foo_chronflow)}}

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2019-06-06T09:25:42Z

Chronial: update version

{{Foobar Component Infobox
| name = Chronial's Coverflow
| screenshot = [[Image:foo_chronflow.jpg|256px]]
| caption = Chronial's Coverflow
| module_name = foo_chronflow
| maintainer = Christian Fersch [Chronial]
| stable_release = N/A
| preview_release = 0.5.1
| preview_release_date = 2019-05-16
| foobar2000_version = 1.3.3
| foobar2000_ui_module = Default UI, Columns UI
| use = UI
| license = GPL
| discussion_thread = [http://hydrogenaud.io/index.php/topic,108450.0.html Hydrogenaudio Forums]
}}

'''Chronial's Coverflow''' is a coverflow plugin for foobar2000. This plugin provides a UI panel that displays a 3d rendering of the albums in your media library.

== Preferences ==
=== Cover Display tab ===


[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

=== Performance tab ===
[[Image:foo_chronflow preferences.png|thumb|300px|Chronflow Preferences page showing the "Performance" tab.]]
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the renderer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

==== Rendering Quality ====
These Settings influence the quality of the generated image.

{{panel|'''Note:''' Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar2000).|color=yellow}}

==== Texture Cache ====
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

==== VSync ====
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 

==== Benchmarking ====
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

==External links==
* [http://github.com/Chronial/foo_chronflow Official website]
* {{ha|https://hydrogenaud.io/index.php/topic,108450.0.html}}

{{DISPLAYTITLE:foobar2000:Components/Chronial's Coverflow (foo_chronflow)}}

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2019-05-16T19:40:54Z

Chronial: /* VSync */ Remove obsolete note

{{Foobar Component Infobox
| name = Chronial's Coverflow
| screenshot = [[Image:foo_chronflow.jpg|256px]]
| caption = Chronial's Coverflow
| module_name = foo_chronflow
| maintainer = Christian Fersch [Chronial]
| stable_release = N/A
| preview_release = 0.5.0
| preview_release_date = 2019-05-16
| foobar2000_version = 1.3.3
| foobar2000_ui_module = Default UI, Columns UI
| use = UI
| license = GPL
| discussion_thread = [http://hydrogenaud.io/index.php/topic,108450.0.html Hydrogenaudio Forums]
}}

'''Chronial's Coverflow''' is a coverflow plugin for foobar2000. This plugin provides a UI panel that displays a 3d rendering of the albums in your media library.

== Preferences ==
=== Cover Display tab ===


[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

=== Performance tab ===
[[Image:foo_chronflow preferences.png|thumb|300px|Chronflow Preferences page showing the "Performance" tab.]]
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the renderer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

==== Rendering Quality ====
These Settings influence the quality of the generated image.

{{panel|'''Note:''' Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar2000).|color=yellow}}

==== Texture Cache ====
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

==== VSync ====
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 

==== Benchmarking ====
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

==External links==
* [http://github.com/Chronial/foo_chronflow Official website]
* {{ha|https://hydrogenaud.io/index.php/topic,108450.0.html}}

{{DISPLAYTITLE:foobar2000:Components/Chronial's Coverflow (foo_chronflow)}}

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2019-05-16T19:40:26Z

Chronial: Update to latest version

{{Foobar Component Infobox
| name = Chronial's Coverflow
| screenshot = [[Image:foo_chronflow.jpg|256px]]
| caption = Chronial's Coverflow
| module_name = foo_chronflow
| maintainer = Christian Fersch [Chronial]
| stable_release = N/A
| preview_release = 0.5.0
| preview_release_date = 2019-05-16
| foobar2000_version = 1.3.3
| foobar2000_ui_module = Default UI, Columns UI
| use = UI
| license = GPL
| discussion_thread = [http://hydrogenaud.io/index.php/topic,108450.0.html Hydrogenaudio Forums]
}}

'''Chronial's Coverflow''' is a coverflow plugin for foobar2000. This plugin provides a UI panel that displays a 3d rendering of the albums in your media library.

== Preferences ==
=== Cover Display tab ===


[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

=== Performance tab ===
[[Image:foo_chronflow preferences.png|thumb|300px|Chronflow Preferences page showing the "Performance" tab.]]
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the renderer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

==== Rendering Quality ====
These Settings influence the quality of the generated image.

{{panel|'''Note:''' Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar2000).|color=yellow}}

==== Texture Cache ====
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

==== VSync ====
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

==== Benchmarking ====
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

==External links==
* [http://github.com/Chronial/foo_chronflow Official website]
* {{ha|https://hydrogenaud.io/index.php/topic,108450.0.html}}

{{DISPLAYTITLE:foobar2000:Components/Chronial's Coverflow (foo_chronflow)}}

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-07-27T13:29:41Z

Chronial: /* Cover Display Tab */

{{Foobar Component Infobox
| name = foo_chronflow
| screenshot = [[Image:Coverflow.PNG|247px]]
| caption = Chronial's Coverflow
| maintainer = [http://www.hydrogenaudio.org/forums/index.php?showuser=21825 Chronial]
| stable_release = n/a
| preview_release = [http://chron.visiondesigns.de/foobar2000/foo_chronflow_v0.3.0.zip 0.3.0]
| foobar_version = 0.9.5
| use = -
| license = -
| website = [http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55607&view=findpost&p=559186 Author's post]
| discussion_thread = [http://www.hydrogenaudio.org/forums/index.php?showtopic=55607 Hydrogenaudio Forums]
}}

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==


[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:25:35Z

Chronial: /* VSync */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If it is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:25:01Z

Chronial: /* VSync */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes too much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:24:26Z

Chronial: /* VSync */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, causing quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:22:32Z

Chronial: /* Texture Cache */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to the size the covers actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:19:55Z

Chronial: /* Rendering Quality */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of them more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-25T11:18:28Z

Chronial: /* Performance Tab */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image and one thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-16T02:38:32Z

Chronial: /* Cover Display Tab */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
'''Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.'''

[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-16T02:37:41Z

Chronial: /* Cover Display Tab */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
Note that only the currently used Cover Display Config is stored (and exported) with your columns_ui/panels_ui config, the other ones are stored in the default foobar config.
[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-16T02:37:07Z

Chronial: /* Cover Display Tab */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-16T00:08:57Z

Chronial: /* Settings */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Cover Display Tab ==
[http://msdn2.microsoft.com/en-us/library/x85xxsf4(VS.80).aspx JScript reference]

== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-11T14:43:04Z

Chronial: /* Benchmarking */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and no tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

The current version contains a bug that will only show fps info if foobar is started with this setting enabled.

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-10T09:20:07Z

Chronial: /* VSync */

Foobar2000redirect:37835416-4578-4AAA-A229-E09AB9E2CB9C

2008-04-08T03:13:08Z

Chronial: Redirecting to Foobar2000:Components 0.9/Chronial's Coverflow (foo chronflow)

#REDIRECT [[Foobar2000:Components 0.9/Chronial's Coverflow (foo chronflow)]]

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:56:23Z

Chronial: /* Benchmarking */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and on tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===
;Display speed information (fps, ms per frame)
:This displays information about the rendering speed in the panel. The panel has to be large enough for it to be visible, otherwise it won't be drawn. The information displayed is to be interpreted in the following way:
:*'''fps:''' displays the average FPS (averaged over 30 frames)
:*''' min:''' displays the fps for the one frame of the last 30 frames that took the longest to display
:*'''cpu-ms/f:''' this number shows the amount of time the plugin spend to generate the information for the frame and pass it to the GPU. upload duration is also added to this number. It's rather difficult to interpret this number, but if it is way lower than (1000ms/refresh rate) and your fps are lower than your fps, there is quite probably something wrong with the VSync Sleep()
:*''' max:''' same as for frames, but for the cpu-ms/f

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:46:05Z

Chronial: /* VSync */

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Performance Tab ==
To understand the effect of the settings in the performance tab it is important to know the basic architecture of the plugin:
The plugin has two threads - one thread to render the image on thread to cache the cover textures. 
The image will only be rendered when it is needed - eg. when you restore the foobar window, new textures have been loaded or an animation is shown. While foobar is minimized or completely hidden behind any windows the renderer will do nothing at all and so also cause no load for your cpu. 
The texture loading thread loads the covers from you hard-disk into memory so the rederer can display them. This is done in an asynchronous manner (you can see this by scrolling very fast - the covers move faster than the loader can load them -> you see the "hourglass cover"). Once the texture cache is filled, the loader sleeps until you move the covers again. See [[#Texture Cache]] for further details.

=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality, but also increased GPU/CPU+GPU load - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===
Each time you move the display to a new cover, the texture loader makes sure that at least ''cache size''*0.9 covers around the selected cover are loaded. 
The covers are loaded into '''GPU memory''', so this also the limiting element for your cache. Remember that there are multiple other applications that use your GPU and all share its memory. So setting the texture cache too large will influence video playback, other multimedia applications as well as games. 
The texture loading process works this way: the background loader loads the image into memory and resizes it to the ''maximum texture size'', then the image is moved into GPU memory and compressed. This is called uploading. During the uploading the renderer has to pause, and as the uploading can take rather long (we only have 13ms to render a frame at 60fps) it is only done when there is no animation displayed or when a preloaded image comes into view.
; Cache Size: The number of covers that will be cached. This should always be larger than the number of covers displayed at once, because otherwise there will be uploading at nearly every frame what might slow down you rendering severely. But setting this to high might be too much for your GPU memory, thus slowing down you whole system.
; Maximum Texture Size: The maximum sidelength for the textures. All covers will be shrinked to fit in a square with this sidelength. Decreasing this setting will lower the needed GPU memory as well as the upload time. Note that, depending on your GPU this might be rounded down to the next power of two. You have to reload the texture cache for this to take effect (do this by pressing ctrl+F5 in the panel).
: You should try to set this to size the cover actually have inside the panel. This can heavily increase texture quality, since the shrinking done during loading produces way better quality than shrinking done during rendering
; Enable Texture Compression : This will quite heavily reduce the amount of GPU memory used by the covers (on my system it went down to 1/6), but will also increase the texture uploading time.
; Texture Loading Thread Priority: You can decrease the priority of the texture loading. You can try to change this when you experience slow rendering, but the default should be alright in most cases.
; Empty cache when window is minimized: This will cause the texture cache to be cleared when you minimize the foobar window. This makes it available for games or video display, but when you restore the foobar window, the covers will have to be loaded again.

=== VSync ===
You can choose between 3 different Settings for VSync:
;No Vsync + try to hit VBlank with Sleep() : This is actually no VSync, but the framerate is limited by the renderer sleeping some time between each frame. This has the lowest CPU usage of the 3 options, but you do not get the benefits of VSync -> you might experience tearing. You should try this setting and if you do not see any annoying tearing you should stick with it, since it delivers best performance.
;Vsync + try to hit VBlank with Sleep(): This enables VSync, but since some GPUs (mine for example) cause 100% CPU usage while waiting for VBlank (the moment at which you monitor has finished displaying the old picture), the renderer tries to sleep some time here to reduce CPU usage. This can cause a severe CPU usage reduction against pure VSync - at my system it dropped from 100% to 20%. But if another process takes to much time the renderer might miss VBlank, cause quite a drop in framerate.
;Vsync only: Just activates VSync. If VSync is well implemented by your GPU (it is not by NVidia GPUs), this will give you high framerate, good CPU usage and on tearing. If is not well implemented you will get high framerate and no tearing but 100% cpu usage during animation.
Note that the Sleep() modes need to know your display's refresh rate. If you have a multi-monitor system with different refresh rates among the monitors and foobar not running on the primary display, the plugin might not be able to guess the right refresh rate. 
If your refresh rate is 100hz, the plugin limits itself to 50fps, since you can't see 100fps after all.

=== Benchmarking ===

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:34:00Z

Chronial: /* Texture Cache */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:32:55Z

Chronial: /* Texture Cache */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:32:23Z

Chronial: /* Texture Cache */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:25:16Z

Chronial: /* Texture Cache */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:21:28Z

Chronial: /* Settings */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:13:02Z

Chronial: /* Settings */

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:07:44Z

Chronial:

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T01:04:36Z

Chronial:

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T00:59:40Z

Chronial:

= Description =
Coverflow...
This plugin is still in beta developement and should not be used if you are affraid of bugs or crashes!

= Settings =
== Performance Tab ==
=== Rendering Quality ===
These Settings influence the quality of the generated image.
While multisampling only increases the smoothness of the cover edges, supersampling also does increase the cover resizing quality. But while multisampling only increases the load on the GPU, supersampling also increases the load on the CPU. For both of the more passes means more quality - supersampling with 2 passes should yield enough quality and settings above 4 should barely make any difference. You should not use 16 pass supersampling, as it is very CPU and GPU intensive (the image is rendered 16 times!).
Changes to the multisampling settings will only take effect after the panel is restarted (either hide and show it or restart foobar)

=== Texture Cache ===

=== VSync ===

=== Benchmarking ===

Foobar2000:Components/Chronial's Coverflow (foo chronflow)

2008-04-08T00:47:35Z

Chronial: New page: = Description = Coverflow... = Settings = == Performance Tab ==

= Description =
Coverflow...

= Settings =
== Performance Tab ==

Foobar2000:Components 0.9/Winamp API Emulator (foo winamp spam)

2007-02-26T20:02:39Z

Chronial:

#REDIRECT [[Foobar2000:0.9 Winamp Spam (foo winamp spam)]]

Foobar2000redirect:D6E376C3-3C15-4E70-9ACB-1E4B32493722

2006-12-11T17:17:07Z

Chronial:

#REDIRECT [[Foobar2000:0.9 Winamp Spam (foo winamp spam)]]

Foobar2000:0.9 Winamp Spam (foo winamp spam)

2006-12-11T17:16:25Z

Chronial:

Foobar2000:0.9 Winamp Spam (foo winamp spam)

2006-12-10T12:34:44Z

Chronial: Removed GTalk Paragraph

'''foo_winamp_spam''' emulates a Winamp 2.x window so existing plugins you have that use the '''Winamp API''' can continue to work with foobar2000 with minimal trouble.

=Description=
This component was primarily designed to be used in conjunction with an mIRC song reporting DLL, [http://www.r1ch.net/stuff/r1dll/ r1dll]. However it is known to work with most software packages that use the Winamp API such as ''EvilLyrics''.

The component works primarily by creating a window with the Winamp 1.x classname and setting the current song title to it. This allows programs to find the Winamp window handle in order to send further messages. The most used parts of the Winamp API are already implemented, but if your application does not work with foo_winamp_spam, feel free to [http://www.hydrogenaudio.org/forums/index.php?showtopic=47155 ask for implementation].

=Links=
*[http://chron.visiondesigns.de/foobar2000/#foo_winamp_spam Component Homepage]
*[http://www.r1ch.net/stuff/foobar/ Component Homepage for Foobar2000 0.7 and 0.8]
*[http://www.hydrogenaudio.org/forums/index.php?showtopic=47155 Discussion Thread]

=Links=
*[http://www.r1ch.net/stuff/r1dll/ Homepage]
*[http://r-1.ch/foo_winamp_spam-0.9beta3.7z Download Foobar2000 0.9 Compatible Beta (7z compressed)]
*[http://www.r1ch.net/stuff/foobar/foo_winamp_spam-0.74.zip Download latest stable release (0.74) (9.33kb, released 29 January 2004) (Foobar 0.8)]

Foobar2000:0.9 Winamp Spam (foo winamp spam)

2006-12-10T11:57:42Z

Chronial: /* Description */ Updated

'''foo_winamp_spam''' emulates a Winamp 2.x window so existing plugins you have that use the '''Winamp API''' can continue to work with foobar2000 with minimal trouble.

=Description=
This component was primarily designed to be used in conjunction with an mIRC song reporting DLL, [http://www.r1ch.net/stuff/r1dll/ r1dll]. However it is known to work with most software packages that use the Winamp API such as ''EvilLyrics''.

The component works primarily by creating a window with the Winamp 1.x classname and setting the current song title to it. This allows programs to find the Winamp window handle in order to send further messages. The most used parts of the Winamp API are already implemented, but if your application does not work with foo_winamp_spam, feel free to [http://www.hydrogenaudio.org/forums/index.php?showtopic=47155 ask for implementation].

=Links=
*[http://chron.visiondesigns.de/foobar2000/#foo_winamp_spam Component Homepage]
*[http://www.r1ch.net/stuff/foobar/ Component Homepage for Foobar2000 0.7 and 0.8]
*[http://www.hydrogenaudio.org/forums/index.php?showtopic=47155 Discussion Thread]

=Applications=

==Google Talk (Gtalk)==
The latest release of Gtalk (as of Aug 2006) includes the ability to display currently playing music and log this to your google account (if you want it to). The client natively supports Winamp, iTunes, WMP, etc. however lacks foobar2000 compatability. It is possible to use the '''foo_winamp_spam''' component to show songs foobar is playing: [http://www.hydrogenaudio.org/forums/index.php?showtopic=47155 Hydrogenaudio Discussion]

=Links=
*[http://www.r1ch.net/stuff/r1dll/ Homepage]
*[http://r-1.ch/foo_winamp_spam-0.9beta3.7z Download Foobar2000 0.9 Compatible Beta (7z compressed)]
*[http://www.r1ch.net/stuff/foobar/foo_winamp_spam-0.74.zip Download latest stable release (0.74) (9.33kb, released 29 January 2004) (Foobar 0.8)]

Foobar2000:Encouraged Tag Standards

2006-12-06T03:15:15Z

Chronial: /* PLAY_DATE and PLAY_TIME */

{{fb2k}}
== Disclaimer ==
The guidelines described in this document have been agreed upon by a group of foobar2000 users and titleformatting scripts authors. Adherence to these guidelines is not required to be able to use foobar2000, though some components or pre-made titleformatting scripts may require or enforce the use of a particular tag.

== Discussion and comments ==
You can leave comments about this page on the [[Foobar2000_Talk:Encouraged_Tag_Standards|Talk page]]. However, real discussion, proposals for new tag-standards, and decisions should happen in the [http://www.hydrogenaudio.org/forums/index.php?showtopic=31530 forum-thread], because more people will notice it there and be able to give input.

== Codesnippets and foobar2000 versions ==
The codesnippets are meant for use in Foobar2000 v0.9. Because of the new field-remappings introduced in v0.9, they do not work with older versions of foobar2000.

== General Tag Construction ==

* Use an easily understood English field name.
* Prefix album-related information with "ALBUM ", ie. "ALBUM ARTIST", "ALBUM SUBTITLE".
* Avoid use of non-alphabetical characters. For serial fields (for a bad example, FIELD1, FIELD2, etc.), merely enter them in the order that you wish them to be read in.
* Try to avoid the use of underscores. Spaces are easier to type, more legible, and as easily useable in Tagz. Spaces are also preferable to no spaces.

== Overview of Current Recommendations ==

FIELD NAME [format] (component)

* ALBUM ARTIST [e.g., Various Artists, The Foobar Collective] (none) ''Notes'': Field name is ALBUM ARTIST, with ''no underscore''. Tag should exist if and only if an album is by multiple artists, and be contained in every track. Track-specific artists should be entered in the ARTIST tag, never in the TITLE tag. [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#ALBUM_ARTIST (more about this standard)]
* FIRST_PLAYED and LAST_PLAYED [2005-03-22 19:00:00...] ([http://www.hydrogenaudio.org/forums/index.php?showtopic=20719 foo_playcount]) ''Notes'': These two tags use underscores instead of spaces - reason for this was to make it consistent with the already existing PLAY_COUNTER-tag. Any amount or type of data may be placed after the time. Compliant TAGZ code shall use $substr() instead of $right() when extracting substrings from this field. ''See also'': [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Tips_%26_Tricks#Standardize_my_PLAY_DATE_and_PLAY_TIME_fields Standardize my PLAY_DATE and PLAY_TIME fields] [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#FIRST_PLAYED_and_LAST_PLAYED (more about this standard)]

=== ALBUM ARTIST ===
''Basics'':
*the tag-fieldname used for declaring and describing albums/split-EPs or split-singles which contain various artists is "ALBUM ARTIST" (separated with space, not underscore)
*tag should only exist if an album contains various artists. It should NOT be created when an album does not contain various artists.
*the tag can contain the overall artist of an album (like e.g. "the foo-bar collective",) multiple artists (e.g. with split-EPs) or if an album does not have a clear overall artist (for example with compilations) just "Various Artists". Simply said: you're free to enter whatever you like as long as it describes the overall album-wide artist(s).
*every track in a V.A.-album has to contain this tag with the same value
*the track-specific artist should be entered into the ARTIST-tag
*the TITLE-tag should only contain the track-title

''Reasons for this standard'':
*it solves all issues regarding albums which contain multiple artists with just one tag
*it is already in widespread use
*sortable and searchable with low effort
*keeping the ARTIST-tag trackspecific allows to find tracks in V.A.-albums as well when searching for a certain artist (DB-friendly)
*keeping the TITLE-tag title-specific allows sorting and searching of V.A.-albums by title (DB-friendly)
*allows meaningful determination and display of V.A.-Albums with a minimum amount of code
*avoids resource-hungry and unsafe "guessing" of V.A.-albums via the filepath
*easy to remember and type in manually
*does not disrupt existing systems when the ARTIST- and TITLE-tag are already track specific (easy transition)
*can coexist with additional directory-based sorting and marking
*can be used for split-EPs and split-singles as well
*supported by [[Foobar2000:Titleformat_Reference#Field_remappings|Field Remappings]] in foobar2000 0.9

''Code snippets'':

// check if an album is V.A.
$if($meta_test(album artist),$puts(album_is_va,1))

// For sorting by artist in an album-context replace %artist% - %album% with:
%album artist% - %album%

// singlemode display without %album artist%-support
[%artist% - ][%album% - ][%title%]

// singlemode display with %album artist%-support
// note: if your display supports both, albummode and singlemode, then you
// may want to use the above version instead in singlemode - depends on taste
[%album artist% - ][%album% - ][%track artist% - ][%title%]

// How to easily integrate %album artist% into an albummode-display:
// in the albummode-column, replace %artist% with:
[%album artist%]
// in the title-column, replace %title% with:
[%track artist% - ][%title%]

=== FIRST_PLAYED and LAST_PLAYED ===
''Basics'':
* the tag-fieldname used for storing info when a song was played the first time is "FIRST_PLAYED"
* the tag-fieldname used for storing info when a song was played the last time is "LAST_PLAYED"
* tags contain date and time in the following format at the beginning: "YYYY-MM-DD HH:MM:SS" (with 24hours-format)
* additional info may be appended after the above info

''Reasons for this standard'':
* the [http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/time.html APE-dateformat] (derived from ISO) is internationally neutral
* sortable
* easily readable and recognizable
* format can be verified with TAGZ
* can be included in formatting-strings without reformatting it (pro for amateur tagz-coders)
* choosing a new fieldname avoids confusion with the existing ambigious play_date tag
* field name is easy to understand/recognize/remember and short enough to type in manually

''Code snippets'':

// verify tag-format (we check the pos. of the first dash and ":")
// using $len for verification is strongly unrecommended!
$if(
$and($strcmp($strstr(%last_played%,-),5),$strcmp($strstr(%last_played%,:),14))
,$puts(last_played_is_valid,1)
)

// disassemble the timestamp for later reformatting or calcuations
$puts(last_played_year,$substr(%last_played%,1,4))
$puts(last_played_month,$substr(%last_played%,6,7))
$puts(last_played_day,$substr(%last_played%,9,10))
$puts(last_played_hour,$substr(%last_played%,12,13))
$puts(last_played_min,$substr(%last_played%,15,16))
$puts(last_played_sec,$substr(%last_played%,18,19))

// display only the date of last_played (without reformatting)
$left(%last_played%,10)

// display only the time of last_played (without reformatting)
// the use of $right is strongly unrecommended!
$substr(%last_played%,12,19)

The above code-snippets can be used for FIRST_PLAYED as well (just replace last_played with first_played).

== Obsolete and Deprecated Tag Standards ==

=== PLAY_DATE and PLAY_TIME ===

Deprecated tags produced by old versions of foo_playcount. Default format DDMMYY for PLAY_DATE and HHMMSS (24hr) for PLAY_TIME. See [[Foobar2000:Encouraged Tag Standards#FIRST_PLAYED and LAST_PLAYED|FIRST_PLAYED and LAST_PLAYED]].

Foobar2000:Encouraged Tag Standards

2006-12-06T03:14:47Z

Chronial: /* PLAY_DATE and PLAY_TIME */

{{fb2k}}
== Disclaimer ==
The guidelines described in this document have been agreed upon by a group of foobar2000 users and titleformatting scripts authors. Adherence to these guidelines is not required to be able to use foobar2000, though some components or pre-made titleformatting scripts may require or enforce the use of a particular tag.

== Discussion and comments ==
You can leave comments about this page on the [[Foobar2000_Talk:Encouraged_Tag_Standards|Talk page]]. However, real discussion, proposals for new tag-standards, and decisions should happen in the [http://www.hydrogenaudio.org/forums/index.php?showtopic=31530 forum-thread], because more people will notice it there and be able to give input.

== Codesnippets and foobar2000 versions ==
The codesnippets are meant for use in Foobar2000 v0.9. Because of the new field-remappings introduced in v0.9, they do not work with older versions of foobar2000.

== General Tag Construction ==

* Use an easily understood English field name.
* Prefix album-related information with "ALBUM ", ie. "ALBUM ARTIST", "ALBUM SUBTITLE".
* Avoid use of non-alphabetical characters. For serial fields (for a bad example, FIELD1, FIELD2, etc.), merely enter them in the order that you wish them to be read in.
* Try to avoid the use of underscores. Spaces are easier to type, more legible, and as easily useable in Tagz. Spaces are also preferable to no spaces.

== Overview of Current Recommendations ==

FIELD NAME [format] (component)

* ALBUM ARTIST [e.g., Various Artists, The Foobar Collective] (none) ''Notes'': Field name is ALBUM ARTIST, with ''no underscore''. Tag should exist if and only if an album is by multiple artists, and be contained in every track. Track-specific artists should be entered in the ARTIST tag, never in the TITLE tag. [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#ALBUM_ARTIST (more about this standard)]
* FIRST_PLAYED and LAST_PLAYED [2005-03-22 19:00:00...] ([http://www.hydrogenaudio.org/forums/index.php?showtopic=20719 foo_playcount]) ''Notes'': These two tags use underscores instead of spaces - reason for this was to make it consistent with the already existing PLAY_COUNTER-tag. Any amount or type of data may be placed after the time. Compliant TAGZ code shall use $substr() instead of $right() when extracting substrings from this field. ''See also'': [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Tips_%26_Tricks#Standardize_my_PLAY_DATE_and_PLAY_TIME_fields Standardize my PLAY_DATE and PLAY_TIME fields] [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#FIRST_PLAYED_and_LAST_PLAYED (more about this standard)]

=== ALBUM ARTIST ===
''Basics'':
*the tag-fieldname used for declaring and describing albums/split-EPs or split-singles which contain various artists is "ALBUM ARTIST" (separated with space, not underscore)
*tag should only exist if an album contains various artists. It should NOT be created when an album does not contain various artists.
*the tag can contain the overall artist of an album (like e.g. "the foo-bar collective",) multiple artists (e.g. with split-EPs) or if an album does not have a clear overall artist (for example with compilations) just "Various Artists". Simply said: you're free to enter whatever you like as long as it describes the overall album-wide artist(s).
*every track in a V.A.-album has to contain this tag with the same value
*the track-specific artist should be entered into the ARTIST-tag
*the TITLE-tag should only contain the track-title

''Reasons for this standard'':
*it solves all issues regarding albums which contain multiple artists with just one tag
*it is already in widespread use
*sortable and searchable with low effort
*keeping the ARTIST-tag trackspecific allows to find tracks in V.A.-albums as well when searching for a certain artist (DB-friendly)
*keeping the TITLE-tag title-specific allows sorting and searching of V.A.-albums by title (DB-friendly)
*allows meaningful determination and display of V.A.-Albums with a minimum amount of code
*avoids resource-hungry and unsafe "guessing" of V.A.-albums via the filepath
*easy to remember and type in manually
*does not disrupt existing systems when the ARTIST- and TITLE-tag are already track specific (easy transition)
*can coexist with additional directory-based sorting and marking
*can be used for split-EPs and split-singles as well
*supported by [[Foobar2000:Titleformat_Reference#Field_remappings|Field Remappings]] in foobar2000 0.9

''Code snippets'':

// check if an album is V.A.
$if($meta_test(album artist),$puts(album_is_va,1))

// For sorting by artist in an album-context replace %artist% - %album% with:
%album artist% - %album%

// singlemode display without %album artist%-support
[%artist% - ][%album% - ][%title%]

// singlemode display with %album artist%-support
// note: if your display supports both, albummode and singlemode, then you
// may want to use the above version instead in singlemode - depends on taste
[%album artist% - ][%album% - ][%track artist% - ][%title%]

// How to easily integrate %album artist% into an albummode-display:
// in the albummode-column, replace %artist% with:
[%album artist%]
// in the title-column, replace %title% with:
[%track artist% - ][%title%]

=== FIRST_PLAYED and LAST_PLAYED ===
''Basics'':
* the tag-fieldname used for storing info when a song was played the first time is "FIRST_PLAYED"
* the tag-fieldname used for storing info when a song was played the last time is "LAST_PLAYED"
* tags contain date and time in the following format at the beginning: "YYYY-MM-DD HH:MM:SS" (with 24hours-format)
* additional info may be appended after the above info

''Reasons for this standard'':
* the [http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/time.html APE-dateformat] (derived from ISO) is internationally neutral
* sortable
* easily readable and recognizable
* format can be verified with TAGZ
* can be included in formatting-strings without reformatting it (pro for amateur tagz-coders)
* choosing a new fieldname avoids confusion with the existing ambigious play_date tag
* field name is easy to understand/recognize/remember and short enough to type in manually

''Code snippets'':

// verify tag-format (we check the pos. of the first dash and ":")
// using $len for verification is strongly unrecommended!
$if(
$and($strcmp($strstr(%last_played%,-),5),$strcmp($strstr(%last_played%,:),14))
,$puts(last_played_is_valid,1)
)

// disassemble the timestamp for later reformatting or calcuations
$puts(last_played_year,$substr(%last_played%,1,4))
$puts(last_played_month,$substr(%last_played%,6,7))
$puts(last_played_day,$substr(%last_played%,9,10))
$puts(last_played_hour,$substr(%last_played%,12,13))
$puts(last_played_min,$substr(%last_played%,15,16))
$puts(last_played_sec,$substr(%last_played%,18,19))

// display only the date of last_played (without reformatting)
$left(%last_played%,10)

// display only the time of last_played (without reformatting)
// the use of $right is strongly unrecommended!
$substr(%last_played%,12,19)

The above code-snippets can be used for FIRST_PLAYED as well (just replace last_played with first_played).

== Obsolete and Deprecated Tag Standards ==

=== PLAY_DATE and PLAY_TIME ===

Deprecated tags produced by old versions of foo_playcount. Default format DDMMYY for PLAY_DATE and HHMMSS (24hr) for PLAY_TIME. See [[Foobar2000:Encouraged Tag Standards#FIRST PLAYED and LAST PLAYED| FIRST_PLAYED and LAST_PLAYED]].

Foobar2000:FAQ

2006-11-18T20:01:23Z

Chronial: grammar

{{fb2k}}
A rather extensive FAQ is available at the [http://shsc.info/foobar2000 SH/SC Wiki].

= General =

== Is foobar2000 still under active development? ==
Yes. Please see the forum and the foobar2000 homepage for the latest version and news about upcoming versions.

== I have Windows Vista and my foobar2000 has stange behavior. Do you plan on fixing those bugs soon? ==
Foobar2000 already fully supports Windows Vista. Some components do not. Try to look for the latest version of those third-party plugins as they might get fixed soon.

== I'm looking for a specific feature. How should I know if a third-party plugin suits my needs ? ==
If you are not the Ctrl+F kind of person with your web browser, this is the perfect opportunity for you to get familiar with it. Go to the [[Foobar2000:Components_0.9|components section]], press Ctrl+F and search for keywords related to what you are looking for (yeah, like google). You will hopefully find something that suits you. Otherwise, maybe you can make a request in the foobar2000 forum or even better, code it yourself then share it with the community!

= Playback =

== There are multiple output methods available: DirectSound, waveOut and Kernel Streaming. Which one should I use? ==
The default setting (waveOut) is recommended; it should be safe to use anywhere. Using DirectSound results in better performance (less CPU overhead)—especially under Windows 2000, Windows XP or newer—but there shouldn't be any audible difference between the two. In certain rare cases, Kernel Streaming may produce better results than DirectSound/waveOut (if for some reason you need data sent through digital out to be bit-identical to source stream); however, bit-identical results with DirectSound have been reported on soundcards capable of mixing multiple streams in hardware (with hardware mixing enabled in DirectSound settings).

Please note that Kernel Streaming is an experimental feature with known issues, and using it is ''not'' recommended unless you have a clear need to do so. Most of perceived "sound quality differences" between DirectSound and Kernel Streaming are related to the fact that Kernel Streaming usually bypasses the Windows volume control. In addition, Kernel Streaming only works on Windows 2000, Windows XP or newer.

== How can I send my files from Windows Explorer into a specific playlist, so as not to erase my current playlist? ==

Preferences → General → Always send to playlist (playlist name)

== Why can't I listen to unfinished downloading files? ==
Foobar2000 needs exclusive access to the file. A good workaround is to copy the unfinished file, then try to play it.

= Look & Feel =

== I just saw a great looking foobar2000 window, but I don't know how to get mine looking the same way! Is there no hope for me? ==
Of course there is! First take a look at those threads and get in touch with what other users achieved:
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=43077 Foobar Gallery] {{foobar2000v09}}
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=30988 Foobar Gallery] {{foobar2000v08}}

Then, you are ready to give it a try! You can find some of the user's configuration in the links below. Note that [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:0.9_Single_Column_Playlist_%28foo_uie_single_column_playlist%29 Single Column Playlist] and [http://yuo.be/columns.php ColumnUI] are standalone components that you need to download.
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=49783 Single Column Playlist settings database]
* [http://foobar.nub4life.net/columns/ Columns UI settings database]
** [http://www.hydrogenaudio.org/forums/index.php?showtopic=31509&hl=foobar+gallery Navigator-Suite]
** [http://www.hydrogenaudio.org/forums/index.php?showtopic=33450 Azrael]
* [http://pelit.koillismaa.fi/fb2k/index.php foobar2000 formatting]

== Is there a way to make my instant messenger's "Now Playing" show the song I'm listening to with foobar? ==
Yes, through plugins:

* [http://www.hydrogenaudio.org/forums/index.php?showtopic=10632 AMIP] Complete now-playing plug-in for mIRC, PIRCH, Klient, Bersirc, other IRC and Mail clients, supporting full player control from mIRC, playlist search, clipboard integration, HTTP, dynamic image signatures, etc.
* [http://stephan.kochen.nl/proj/foobar2000.html#msn for MSN]
* [http://pelit.koillismaa.fi/plugins/general.php#76 for Miranda-IM]

== I have seen some people using something which pops up to display the song being listened to. Where can I find it? ==
* It's called [http://www.hydrogenaudio.org/forums/index.php?showtopic=33236&hl=foo_pretty+pop-up foo_prettypop]. Note that it requires the .NET Framework to work.
* If you are using Columns UI, it has a popup notification feature too ("Preferences -> Display -> ColumnsUI -> Status Bar/Systray (tab) -> Show popup notification baloon")

== Is there a way to map my multimedia keyboard keys? ==
You can assign actions with keys including multimedia key from the in "Preference -> General -> Keyboard Shortcuts". If it still does not work, take a look at [http://www.hydrogenaudio.org/forums/index.php?s=39a242a80d03f35b424165dd8e06be6b&showtopic=50067 this] tutorial.

= Columns UI =

== How do I know which component is meant to be used with Columns UI?==
[[Foobar2000:Components_0.9|Component section]] of the wiki shows which plugin you can use for ColumnsUI's interface.

== How can I get tabbed panels? ==
Use [http://www.hydrogenaudio.org/forums/index.php?showtopic=46106&st=0&p=410247&#entry410247 uie tabs].

== Where are the options for changing the playback buttons? ==
Right click on buttons area → Customise...

== How can I display the album art and cover above my playlist? ==
To set the panels above your playlist, just use <tt>list all toolbars</tt>, then add the panels/toolbars/visualizations that you want to use. Organize them as you want them to be displayed. And finally, use the 'minimum height' values of the corresponding panels. As it is not a common way to use the toolbar, you may experience some unexpected behaviour. Keep in mind that it may create some display problems. Musicmusic may fix this into the next version of Columns UI.

== I have more questions. ==
Refer to the [http://yuo.be/wiki/columns_ui:faqs offial ColumnsUI FAQ].

= Database, Tagging & Album Cover =

== Foobar always takes between 5 minutes and several hours to open all the files in the same playlist. Is there a way to reduce this delay? ==

'''0.8.x'''

Sure. Enable the media (Preferences → Core → Database). You will be able to add thousands of files in only 30-40 seconds.

Alternatively, if you don't want to activate the database, just save your playlists in the <tt>fpl</tt> format.

'''0.9.x'''

Database is now known as Media Library ("Preferences → Media Library") and there is no way enable/disable it.

== I updated my tags, but foobar still shows the old tags. How can I fix this? ==
Select the file(s), right click on any of them, go to Tagging, then click on "Reload Info from File(s)".

== How to guess tags based on directory structure? ==
Select all tracks in the playlist → right click → open the "Properties" dialog → chose "Fill Values from File Names" from its context menu.

== Is there a way to have album covers downloaded automatically? ==
Unfortunately, it is not possible. But, there is a way to be 2 clicks away from those cover arts. Take a look at [http://www.hydrogenaudio.org/forums/index.php?showtopic=43429&hl=cover+download this thread] for more info.

= Troubleshooting =

== I get an error message saying "referenced file doesn't exist" on the console. What does that mean, and how can it be fixed? ==
This error is caused by an outdated/broken CUE sheet or APL link. You need to find and repair or remove it. After that, run "Remove dead entries" from the Database page in the Preferences dialog.

== The Album List shows dead entries after restarting, even though I used "Remove dead entries" earlier. Why is that? ==
The files are probably still referenced in one of your playlists or in the history (if you are using an old version of <tt>foo_history</tt>). Use Playlist → Remove dead entries from the main menu on all your playlists, or remove the dead entries manually. As long as the files are on a playlist, they will be in the database and thus will show up in album list.

== Menu items for some plugins don't show up. I reinstalled but I still don't see them, even though the plugin is shown as a Loaded Library. ==
If you delete a menu item for a plugin, and then re-add the plugin, it won't re-add the menu items. The solution is to open the Preferences dialog, go to Core → Main menu items, and add the items manually.

== An MP3 does not play properly (there is no sound) in fb2k whereas it plays perfectly in other players. What is the problem? ==
You need to disable <tt>Use peak info to scale down tracks that still clip after applying replaygain</tt> in the Preferences dialog, in the ReplayGain section of the Playback page.

== I use the volume control toolbar but it doesn't work. What's the problem? ==
You may be using Kernel Streaming or ASIO. These two output methods are not compatible with the volume control toolbar.

== There is always a long delay before changes to the DSPs take effect. Can I reduce this? ==
Try reducing the output buffer length from Preferences → Playback → Output → (your selected output method). However, do not put it at the minimum length. 300ms should be enough (more if you are using several DSPs).

== What are metadb_handle leaks? ==
metadb_handles are resources used in the metadata management in foobar2000. A leak indicates that a component does not release them (in time). The overall effect of such a leak is relatively harmless. Nevertheless, this is a programming error and foobar2000 detects and reports it to the user. Unfortunately, it is not possible for foobar2000 to detect which component caused the leak.

== I hear static when fading in/out - pause/unpause. ==
Be sure you have the latest sound drivers installed and disable your dsp's before reporting it. Some users reported that using [http://foobar2000.org/components/index.html Kernel Streaming] instead of the default output fixed the problem ("Preferences -> Playback -> Output"), but be aware that this plugin is still experimental and it is issue related in some cases.

= Foobar2000 and other players =

== Is foobar really better than Winamp? ==
There is no set answer. According to public opinion, foobar is great for people wanting a minimal player, as well as the opposite: people needing advanced features. However, the medium users are lost between the profusion of settings and components to find. Some relevant links:

* [http://www.hydrogenaudio.org/forums/index.php?showtopic=20322 Tell us why have you chosen foobar2000, or why don't you like it]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=29501&hl=winamp could foobar2000 replace winamp?]

== Is the sound really better with foobar? ==
As the author of foobar says himself, foobar doesn't have a better sound than the other players like Winamp. From a theoretical point of view, the sound from foobar2000 is not different from the sound from other players since a player can't improve the sound drastically (though it might be altered if not correctly set). Your hardware is much more important (audio card, speakers, headphones, even cables), as is the audio source (Audio CD? Lossless codec? Lossy codec?). The software part is only secondary.

Even if sound modifiers ([[Foobar2000:Components_0.9#DSP|DSPs]]) are used, they only widen the gap between the source and the result, which might actually degrade the sound quality.

== I won't leave iTunes, it manages my iPod perfectly! ==
Maybe this will change your mind: [http://www.hydrogenaudio.org/forums/index.php?showtopic=45160&hl=dop foo_dop].

[[Category:foobar2000 Guides|FAQ]]

User talk:Canar

2006-09-24T19:21:52Z

Chronial:

{{talkheader}}
In Reply to you Post on [[User:Chronial|my User Page]]: This is really funny - the editing page says:

"Please note that all contributions to Hydrogenaudio Knowledgebase are considered to be released under the GNU Free Documentation License 1.2 (see Project:Copyrights for details). If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here."

This does not make any sense at all. The GNU FDL does '''not''' permit your writing to be "edited mercilessly and redistributed at will" - you are stating on your edit page that you are willing and going to ignore the copyright of the submitted texts. If you want to do this, you have to state that all submited texts are considered to be released into public domain - not FDL.

To complete the crazyness this whole stuff is not present on the german version of the interface (I don't have to change any settings to see the german version, It's default - I never saw the english version). So everyone whose mother-tongue is not english will not even know about your license-violating plans.

I don't want to complain (already did that on the concerned page ;) and I'm fine with your apology but I just wanted to note that you may be getting yourself into some legal trouble here. --[[User:Chronial|Chronial]] 06:37, 24 September 2006 (CDT)
:wha's hopponin' ere? - GFDL+copyright freak {{User:Elliottmobile/sig2}} 07:34, 24 September 2006 (CDT)
:it seems that Canar is copying from copyrighted websites, right? the websites would have to be public domain BUT posting them here IF THEY WERE PUBLIC DOMAIN would release 'em under GFDL. this is ok because public domain stuff can be done anything with even relicensed. what he's doing is likely illegal, and you should replace the pages with <nowiki>{{copyvio}}</nowiki>. {{User:Elliottmobile/sig2}} 07:40, 24 September 2006 (CDT)
::nope, it's about Canar moving the content of a page 90% created by me from [http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Title_formatting&oldid=4765 Title formatting] to [[Foobar2000:Tagscript]], instead of renaming the page. This results in a FDL violation, since it requires the authors of the text to be named.
::He responed that the wiki says (only with english interface!) "If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here." - but this is still a violation of the FDL, and so HA states that they are gonna violate your rights if you post stuff to the wiki oO.
::This is like a instead of selling a car telling the buyer that you will give it to him for free, but will later come over and rob the money he would have to pay from him. It's just illegal --[[User:Chronial|Chronial]] 08:33, 24 September 2006 (CDT)
:::Please note that all contributions to Hydrogenaudio Knowledgebase are considered to be released under the GNU Free Documentation License 1.2 (see Project:Copyrights for details). If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!
:::That's the actual text, so it's just getting a point across and linking to more info. But yes, that's a copyright violation. I agree. {{User:Elliottmobile/sig2}} 08:35, 24 September 2006 (CDT)

Am I right asuming this will be a non-issue if I merge the histories? [[User:Jan|Jan]] 10:54, 24 September 2006 (CDT)
:Yep. {{User:Elliottmobile/sig2}} 12:47, 24 September 2006 (CDT)

Done :) now be happy! [[User:Jan|Jan]] 13:11, 24 September 2006 (CDT)
:It was allready fine with me when Canar appologized ;). But I wanted to warn you that the sentences "Please note that all contributions to Hydrogenaudio Knowledgebase are considered to be released under the GNU Free Documentation License 1.2 (see Project:Copyrights for details)." and "If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here." are in legal conflict.--[[User:Chronial|Chronial]] 14:21, 24 September 2006 (CDT)

User talk:Canar

2006-09-24T19:21:35Z

Chronial:

User talk:Canar

2006-09-24T13:33:52Z

Chronial:

User talk:Canar

2006-09-24T13:32:45Z

Chronial:

User talk:Canar

2006-09-24T11:37:13Z

Chronial:

In Reply to you Post on [[User:Chronial|my User Page]]: This is really funny - the editing page says:

"Please note that all contributions to Hydrogenaudio Knowledgebase are considered to be released under the GNU Free Documentation License 1.2 (see Project:Copyrights for details). If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here."

This does not make any sense at all. The GNU FDL does '''not''' permit your writing to be "edited mercilessly and redistributed at will" - you are stating on your edit page that you are willing and going to ignore the copyright of the submitted texts. If you want to do this, you have to state that all submited texts are considered to be released into public domain - not FDL.

To complete the crazyness this whole stuff is not present on the german version of the interface (I don't have to change any settings to see the german version, It's default - I never saw the english version). So everyone whose mother-tongue is not english will not even know about your license-violating plans.

I don't want to complain (already did that on the concerned page ;) and I'm fine with your apology but I just wanted to note that you may be getting yourself into some legal trouble here. --[[User:Chronial|Chronial]] 06:37, 24 September 2006 (CDT)

User talk:Canar

2006-09-24T11:36:24Z

Chronial:

User talk:Canar

2005-08-29T07:23:41Z

Chronial:

Please be more careful when moving articles. You should use the wiki's move feature, because the way you move articles breaks the editing history. For example you moved my article [[Foobar2000:Tagscript]], which is almost completely written by me - but there's no trace of this in the version history. 
There are 2 problems with this way of moving articles:
# It might annoy the authors (like it did annoy me)
# It's breaking the rules of the GNU FDL, wich needs all authors to be mentioned
--[[User:Chronial|Chronial]] 02:23, 29 Aug 2005 (CDT)

Foobar2000

2005-08-29T01:04:48Z

Chronial:

#REDIRECT [[Foobar2000:Foobar2000]]

File:Core.png

2005-08-29T00:57:47Z

Chronial:

Foobar2000 Talk:Tagscript

2005-07-08T18:27:13Z

Chronial:

When moving articles, you shold use the moving function of the wiki, for this moves the list of authors, too. [[User:Chronial|Chronial]] 13:27, 8 Jul 2005 (CDT)

Foobar2000 Talk:Tagscript

2005-07-08T18:26:20Z

Chronial:

When moving articles, you shold use the moving function of the wiki, for this moves the list of authors, too.