Skip to main content ↑ ↓
Topic: [Suggestions / Wishlists] for future updates (Read 27437 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: [Suggestions / Wishlists] for future updates

Reply #25 –
Quote from: Skeebadoo on
Dark theme

Now that after decades Microsoft finally got around making explorer dark, maybe, just maybe, we could have it transplanted into foobar's UI instead of the ugly 90s white+grey?
It uses the system theme.

Re: [Suggestions / Wishlists] for future updates

Reply #26 –
Quote from: Skeebadoo on
Dark theme

Now that after decades Microsoft finally got around making explorer dark, maybe, just maybe, we could have it transplanted into foobar's UI instead of the ugly 90s white+grey?

Enable High-contrast themes in win10 personalization to clearly see the effect across application windows.

Alternately you may like something like this: https://www.deviantart.com/eversins/art/GreyEveTheme-FINAL-Windows-10-High-Contrast-Theme-643504863

Re: [Suggestions / Wishlists] for future updates

Reply #27 –
Would it be possible to set a custom location for the intermediate .wav file when pipe encoding instead of using the destination folder? Having the option to use ram would also be a nice option.

Re: [Suggestions / Wishlists] for future updates

Reply #28 –
For consideration: restrictions on what is captured by "* HAS". For example

*tag HAS: searches in a default set of tags. For example, those selected in Properties -> Advanced -> Display -> Properties dialog
*anytag HAS: searches in all tags, but leave out path and info fields.  [Well, should it count replaygain fields, that fb2k anyway treats different, i.e. does not show in the Metadata tab under Properties?]
* HAS: as today

or: *default HAS vs *tag HAS vs * HAS or something like that.

or, different scheme:

*tag(artist,publisher,myownverystupigtagfield) HAS: searches only in these, a shorter way of using repeated OR
Then one can have *tag() HAS to represent a default set and *tag(*) HAS for "anywhere".

or (obvious disadvantage of breaking known behaviour):

* HAS: change into searching only preconfigured fields.
** HAS: searches all tags
*** HAS: searches everything today's * HAS does.
High Voltage socket-nose-avatar

Re: [Suggestions / Wishlists] for future updates

Reply #29 –
Quote from: Wipsigoh on
Would it be possible to set a custom location for the intermediate .wav file when pipe encoding instead of using the destination folder? Having the option to use ram would also be a nice option.
By the very definition, there is no on-disk intermediate .wav file when pipe encoding.

Re: [Suggestions / Wishlists] for future updates

Reply #30 –
Feature request:
I notice that converting flac to wav and wav64 gives a better sound. I assume it sounds better coz it takes less cpu to process in real-time. I use 50ms buffer to observe this quality bump.

I've also been enjoying the improved sound quality  using the RAM-DISK component.

My request is the ability to load a 'converted to wav64 32bit' version of the flac file on the playlist to RAM-DISK.so even if a FLAC version is on the playlist, a modified version of RAM-DISK will load a wav64 32bit version of the file to RAM. I got this idea from JRiver and it's 'load decoded file to memory' feature and it works very well when I did a manual version of it on foobar.

Re: [Suggestions / Wishlists] for future updates

Reply #31 –
What a fine example of placebo doing its thing. FLAC and WAV will both decode so fast that your machine's power states won't change one way or another. There's no way even in theory that they would produce different sound. Also RAM-DISK won't improve audio quality, audio will already be cached in decoded form in the output buffer. Though you for some reason decide not to utilize it by setting the output buffer to its minimum size. It won't improve quality, it will only open a possibility for data dropouts which will be very audible glitches.

Re: [Suggestions / Wishlists] for future updates

Reply #32 –
Speak for yourself, mate cause I'm hitting a level where I can hear the difference.  I've set the output buffer to the minimum size to increase speed and transparency and my setup has to reduce my cpu core down to one core to reduce noise.

Re: [Suggestions / Wishlists] for future updates

Reply #34 –
Quote from: fbuser on
Quote from: 801evan on
I'm hitting a level where I can hear the difference.
No, you can't. Apart from this, please have a lookt at this.

Just because you don't hear it doesn't mean others can't. Like I said, my current setup uses one core and buffer at the minimal setting. So the least cpu cycles to use on demand helps. While FLAC and WAV data are essentially the same, it's the CPU processing time that makes a difference.

My request is to combine two existing features, the ability to transcode to a certain wav, wav64 flavor and send that to RAM-DISK. There's a reason RAM-DISK was developed and why 'load decoded file to memory' exists as a feature on JRIVER.

Re: [Suggestions / Wishlists] for future updates

Reply #35 –
At a 50ms buffer setting, you will likely notice CPU usage issues with just about any format. Setting buffers that low is totally pointless for an audio player. And even DAW software likely pre-buffers compressed audio for a second or two ahead of playback, for this same reason.

Re: [Suggestions / Wishlists] for future updates

Reply #36 –
I'm on win 2012 + audio optimizer + Fidelizer pro , foobar kernel streaming + ram disk + minimal buffer  to Hugo 2. I can understand how conventionally the difference is neglible,  the SQ difference is noticeable on high quality external DACs. At least 3 other ppl who indulged me in trying it on their system can hear the difference.

Again, just because some people don't hear it, doesn't mean it doesn't exist. And even if such difference is probably null to most people reading this, it doesn't change the difficulty in developing my feature request.

Re: [Suggestions / Wishlists] for future updates

Reply #37 –
"High Quality" external DACs are usually fidgety pieces of crap, riddled with their own issues. You've just listed off so many Wrong Things that could equally stand to have broken your audio processing chain.

I think I'll go back to the safety of my room now, and continue listening to base quality Spotify music (not even using the Premium SUPER HQ BITRATE I technically pay for, but would rather not waste the bandwidth on) on my external USB microphone with monitor DAC that only does 44100/16 and 48000/16 output.

Re: [Suggestions / Wishlists] for future updates

Reply #38 –
Isn't the buffer under Preferences->Playback->Output a set amount of decoded audio? (If not, how can it buffer encoded files that have no proper seektable?)

Quote from: 801evan on
Again, just because some people don't hear it, doesn't mean it doesn't exist.
If you can hear it, it is easy to prove using https://www.foobar2000.org/components/view/foo_abx . Do that first.

But glitches due to too low buffering are usually so obvious that people would just go ahead checking their buffers rather than claiming that it is only audible to their own golden ears. If you really have issues like this, then MP3s would be expected to cough all the time. I have had glitching due to Dell delivering a horrible set of drivers, but format didn't matter then; try LatencyMon https://www.techspot.com/downloads/6944-latencymon.html .

And, I wonder why you try to provoke forth glitches by taking down the buffer, only to buffer the entire song in RAM. IIRC (question on top), increasing the buffer will do what you need. And you can go to Preferences->Advanced->Playback->Full file buffering up to (kB):

High Voltage socket-nose-avatar

Re: [Suggestions / Wishlists] for future updates

Reply #39 –
My system display stays asleep after one minute despite keyboard input and I have keyboard shortcuts to control the playback and I can hear it from there and check afterwards.

Yes, especially on DS, low buffer output craps out. Despite 500ms, I get glitches on DS. So I can understand ppl's reply on my request. Kernel streaming component performance has been amazing and minimal buffer output works and gives the best sound quality. By comparison, higher buffer settings sounds like it's underwater and poor timing in the sound. By poor timing, I mean it can't resolve the micro-details and technicalities. When I get back to a higher buffer setting, I realize I only hear the guitar sound after it's string has been plucked.

I lack understanding why buffer output has noticeable results despite sending the data to RAM but that's my observation.  I've tried that full file buffering option on advanced and that one doesn't change the sound.

Re: [Suggestions / Wishlists] for future updates

Reply #40 –
The longer buffer can't change audio - it's just a buffer holding the samples between the playback thread and the Windows API that requests the data for sound device drivers. What happens in the output is exactly identical, only difference is that with longer buffers the samples that will be played were decoded N milliseconds earlier in advance. If there are no buffer underruns, which would be audible as very loud clicks or pops, timing is absolutely irrelevant. The sound device has its own buffer and its own clock that will play the samples at the rate its clock runs.

If you think your computer is special and things don't work that way could you please record the output from your DAC with the short buffer and with a long buffer where sound is underwatery. Use the same track for both recordings and please share the recordings here for examination.

Re: [Suggestions / Wishlists] for future updates

Reply #42 –
HI, Suggestion to merge the UPnP Media Renderer output into Foobar, and get to have the stream title to display dynamic information like %title% or %artist% or both ? ANd have the vizualisation working on DLNA. Thanks

Re: [Suggestions / Wishlists] for future updates

Reply #43 –
Quote from: kode54 on
By the very definition, there is no on-disk intermediate .wav file when pipe encoding.

Oh, whoops. My mistake. Thanks for pointing that out. I should have referred to when pipe encoding isn't being used.
And I probably should clarify that while it would be nice to have the .wav file in ram, I can see it might not be feasible to implement. If so, the option to set a custom file path for the .wav would be appreciated.  :D 

Though, as I'm generally new and just realized this, I should make sure I'm not still unknowingly asking for pipe encoding by accident.
My understanding is that the audio data is streamed from the decoder (as it's being decoded) directly to the encoder (as opposed to converting to a .wav file in ram to then be encoded). Some encoders don't use pipe encoding because they are expecting a "whole" file as the input. Is that correct?

Many thanks!

Re: [Suggestions / Wishlists] for future updates

Reply #44 –
1.4.1 beta 1 has a setting in advanced preferences to perform encoding in temp directory and move the final file to the target. This is a better version of just using it for temporary wav file.

Re: [Suggestions / Wishlists] for future updates

Reply #45 –
For improve use Internet radio, please consider the following:
1. Allow fb2k to stop playback for non working links at playlist.
See ref: https://hydrogenaud.io/index.php/topic,77715.msg956815.html#msg956815
2. Add %error% for Title Formatting Fields (or another way) to display status of non playable elements at playlist.
See ref: https://hydrogenaud.io/index.php/topic,77715.msg958656.html#msg958656
3. Allow fb2k to add images for internet links of playlist items.

Thanks!

Re: [Suggestions / Wishlists] for future updates

Reply #46 –
4. Pay attention please and standardize to displaying of Internet radio links on the playlist.
To test (for example) three different internet radio links (with different variants of displaying on the playlist):
Spoiler (click to show/hide)
first link: (best variant): when added to the playlist, static information will be displayed for titles fields: %codec%, %samplerate%, %channels%, $meta (genre).
After start playback %bitrate% appears. After stop playback, this information will remain on the playlist (without %bitrate%). Also available information at field "General" of section "Properties / Details".
second link: when added to the playlist, static information will be displayed for only title field %codec%. Сontent for %bitrate% appears after start playback and disappears after stop playback. The field "General" of section "Properties / Details" is absent constantly.
third link: when added to the playlist, static information will be displayed for only title field $meta (genre). During playback content of $meta (genre) on playlist is absent, and appears again when stop playback. Сontent for %bitrate% appears after start playback and disappears during playback. Also the field "General" of section "Properties / Details" is absent constantly.

Re: [Suggestions / Wishlists] for future updates

Reply #47 –
My suggestion
Upnp integrated to foobar and to have the stream title to display dynamic information like %title% or %artist% or both ?
Thanks in advance
 

Re: [Suggestions / Wishlists] for future updates

Reply #48 –
It would be nice to have a small indicator of the media library status (monitoring/initializing/error/whatever) somewhere in the user interface, without clicking a sequence like "Library -> Configure -> Cancel"...
Maybe a %media_library_status% field that could be put in status bar?

Re: [Suggestions / Wishlists] for future updates

Reply #49 –
Is it possible to make foobar2000 able to group convertion presets in custom groups?
 
SimplePortal 1.0.0 RC1 © 2008-2019