Skip to main content

Recent Posts

3rd Party Plugins - (fb2k) / Re: foo_wave_seekbar
Last post by EpicForever -
@Rollin: well, OK... I can leave with that, still good to know that it is something that possibly can be fixed if I dig deeper.

@Zao : if problem with Westbam Mvid is that file itself is malformed and incorrectly reports its length / ffmpeg can not read it properly and pass it to foobar - OK, I have no pretensions that it can not be fixed - totally bad input = bad output
But for other supposedly broken files from the package I only ask for not discarding data that were calculated for initial blocks and displayed before error occurred. Their length is reported properly so base condition for waveform seekbar component exist. I intentionally added there 1 file or 2 files, that display full wavefom, despite they also throw decoding/playback error at the very end. Also I noticed that incomplete downloads still allow to display not disappearing waveform, despite they are also malformed at the time when they still download and playback decoders throw errors on them.

Of course I don't expect anything to be fixed immediately. Just when next release will be planned for whatever reason, you can consider also not clearing seekbar when certain errors occur, but leaving empty space in it instead - as for incomplete downloads happens now.
What kind of noise or distortion does a marginal USB cable make?
None whatsoever.

I don't think that any of the common audiophile descriptions fit.

'course not. Audiophools, not audiophiles, make it look like it behaves as some sort of analogic media, when it is obviously does not.

Being digital, all those zeros and ones will either get to the other side or not, or, in more realistic terms and as Saratoga's pointed out, the device will be recogzined or not. So no "noise" is supposed to be generated from that.

Listening Tests / Re: Directsound vs WASAPI vs ASIO
Last post by sirius! -
It's an old thread but there has been some changes with asio vs wasapi.  With an ASUS essence stx, if use ASIO, it's louder than wasapi but not as much as before the Creator update from windows 10. Wasapi has a better sound now which can be hard to dicern when we don't have the right hardware to listen to it.  ASIO is still the best but Wasapi is VERY close behind.
Also because of the  " creator update" those who own a DAC can see that windows can play now 24/192 at the USB output. IT might be 32/196 but anyway, I've red that it has been changed since the creator update.  Cheers !
@EpicForever Thank you so much, it works. :)
Right, so it is not only safe but also worth to try.

I must admit I am confused. I read a lot that headphones such as sennheiser HD800 are not suitable for DAPS like mine due to their high impedance (300 ohms).

That headphone measures as per below:
Volts RMS required to reach 90dB SPL: 0.242 Vrms
Impedance @ 1kHz: 361 Ohms
Power Needed for 90d BSPL 0.16 mW

So I have been focusing on lower impedance headphones (less that 70 ohms).

This pair of headphones has an impedance of 2k ohms but still they will be driven by my DAP? Did I misread your reply?

2kohm headphone? was that a spelling error?

most headphones run just fine on most DAPs. will they provide the highest fidelity in the world, maybe not. but between dysfunctional and utopian perfection there is still a wide area where things simply work and the music is pretty cool.
a few DAPs won't go very loud so that's already a good reason to check the specs and make an approximation of your needs. then a few DAPs might suck a little into 600ohm but that's also pretty rare. they have way more chances to suck when plugged into some super sensitive 10ohm IEM, based on my limited experience.
@arch21: I found the reason for problems with FLV. Declaration was wrong:
*.flv, *.fla   (note the coma)
while it should be:
*.flv; *.fla  (note the semicolon) - now it works as it should.

Regarding your problem with codec name representation - you need to use function "Tagging / Reload info from file(s)" in context menu for affected files.

@zermy: sure, files seem to have errors and are remuxed already, however if they can be played back as they are - then it would be nice if error handling in any component that is used to process them could still allow to build waveforms for them - but it seems it is up to foo_waveform_seekbar to make it happen.
Also try to delete DeskbandControls.json in config folder and restart explorer, that should fix it, I guess...

I just deleted it, but I sent the file in email to you. My explorer is fine now. If you come up with the reason for conflict, I will try installing again. I like the program, one thing that would cool is the ability to switch playlists.
Ohh, one more thing before the crashes, I also changed the number of songs to be displayed.
Also try to delete DeskbandControls.json in config folder and restart explorer, that should fix it, I guess...
I would like to know what is left on computer after uninstalling, what does the program modify and leaves?

First of all, if you can upload here your config located at C:\Users\%USERNAME%\AppData\Roaming\DeskbandControls\
that would help me to diagnose whats wrong. Also, make sure you are using the latest version.

Thanks for response.
Yes, it is the new version. At first it worked for 5 minutes. But, I tried changing the size of picture, must have hurt the program.
After uninstalling, I tried installing again but it was too late and windows explorer and deskband didn't like each other anymore.
I will send you the .json file.

3rd Party Plugins - (fb2k) / Re: foo_wave_seekbar
Last post by Zao -
I'll start with a disclaimer that I have no intent to fix the code or make any release. It took me over an hour to set up an environment that could build foo_wave_seekbar at all this time, and it's one that isn't fit for making releases with.

If you look closer at the Westbam track, you'll notice that both the playlist, the builtin seekbar and my seekbar agrees that it's around two seconds long. This information is based on what the decoder says about the song length. If I ask about track information, it tells me "oh 88704 samples at a sample rate of 44100".

As this can be an approximation sometimes, I have logic to either pad with silence or truncate, depending on if it the track decodes shorter or longer than expected. Normally this is fine as the difference is a few hundred samples at most.

A difference between the player and my component is that I need a reasonably accurate track length up-front due to how my analysis works. I split the file into parts that are individually filled as I decode. That information needs to be known before I start. The player can just keep decoding until the file ends, producing up to an infinite amount of bonus audio.

As for recovering interrupted playback, I don't believe in producing bogus waveforms. This component kind of has a base assumption that the source is capable of producing what it promises.

For the undersized file, it might be possible to try to decode a bit further than the promised sample count, just to see if the file seems to be overlong enough to make a difference in the waveform. If so, decode to the true end and use that as the sample count for a completely new run of the file. That would work for your 2s track, but would be extremely amusing on infinite songs like looping tracker modules, so nothing one can naïvely implement.

For files that throw exceptions, I assume all are fatal. I cannot distinguish between error kinds there, unless you're supposed to just try to continue decoding and hope for the best.

As some bloke mentioned in the other thread, consider fixing your files.