component updates
updated to foo_uie_wmpvis 0.1.3 (30/09/2007)
- added support for WMP11 ENU 11.0.5721.5230
- fixed crashing when right click to show the menu
updated to foo_dsp_crossfader 0.3.3.2 (28/09/2007)
- bug fix of random crash during seeking when “fade in on seek” is activated
updated to foo_dsp_crossfader 0.3.3.1
- improved a bit silence detection
foo_dsp_crossfader 0.3.3
- allow different fading duration for track change, manual track change and seeking
- integrated skip silence for removing silence in the middle
- allow more interaction with other components
I always wanted to have different fading durations for each situation, but was too lazy, now it’s done, enjoy~
since a lot of change to the config, be sure to remove crossfader from the dsp chain and load with the new config again, otherwise unexpected behavior may happen!
foo_input_mslive 0.3.9
- now can interact with crossfader (requires crossfader 0.3.3+)
- added an option to auto disable crossfader when playing with mslive
Acropolis said,
August 27, 2007 @ 3:30 am
I’ll improve it later, because it is hard coded the value to treat the data as silence.
squeller said,
August 27, 2007 @ 12:56 am
Hmm, I seem to have problems with the gapless part. Middle gapless is always off, and “remove beginning silence” does not matter: Quite often I’ve seen the component eating a bit of the beginning of a track. I.e. not only silence.
I try to find audio snippts and will post them to HA, but not today.
squeller said,
August 22, 2007 @ 1:07 am
OK, it seems I need at least 1300. If 1000 or below, I earn a serious gap.
Acropolis said,
August 21, 2007 @ 11:08 pm
yes, because the samples in the output buffer are being force played, it will hold foobar until it is done.
so the output buffer must be less than 1000ms to make it not obvious enough, and I found 1000 is the most suitable value.
Squeller said,
August 21, 2007 @ 11:00 pm
Thx. for the hint “dsp after crossfader”…
Output device buffer: 2000ms, local aac files, no other dsp… A quick computer at work. Ah OK, it depends on the output buffer, because this is being played fully?
Acropolis said,
August 21, 2007 @ 10:11 pm
hm…
1. it is easier to implement in %, as I said, I’m lazy~.
also, if I implement it in ms, it will need to update the sliders for every changes to the max length slider, quite serious flickers to the window.
2. it works well here, did you use any other DSPs?
I never see the 2-3 seconds problem. and what files are you playing? because the manual fading really depends on the reading/decoding speed. just a note, did u forget the set the output device buffer to 1000ms?
btw, if you have some particular DSPs after crossfader, when doing manual fading, it may have glitch happen, I’ve been trying a lot of methods but still don’t what causes it and how to fix yet.
3. because it is just something next to me when writing the crossfading routine, and it’s useful if not using DS as the output.
Squeller said,
August 21, 2007 @ 9:39 pm
Many thanks, yes, I guess people want a shorter fade on manual track change… Three comments:
1. I’d prefer to have milliseconds for all settings instead percent values
2. Short manual fades don’t work here. The values:
Max length: 5000
Track change: 100%
Manual: 10%
Seek: 5%
When double clicking a playlist entry while playing, it always takes 2 or 3 seconds before something happens, then the new track fades in…
3. Why do you have “fade on seek” implemented? It’s in the fb2k core…
Greetings to Hongkong.