getmusicbee.com
Support => Bug Reports => Topic started by: projeKct on December 16, 2018, 08:05:55 PM
-
I know that this subject has been discussed somewhere, but I can't find the solution.
I love the wavebar feature of MusicBee (in the main player OR in theater mode), but there is a delay between the wavebar progress and the audio: the audio is played a little less than 1 second later.
I have tried to switch between DirectSound and WASAPI with no difference.
The wavebar feature of foobar2000 and AIMP are working great on the same computer.
Can you help, please?
Thanks.
-
More testing...
When we seek by clicking on the wavebar, anywhere within the track, we can sometimes have better syncing. Well... sometimes yes, sometimes no... It's weird.
-
I've noticed this ever since the option to add two wavebars was added. I'm not saying it's because of the two wavebars. I'm just referencing -about- when I started noticing it.
-
Any idea what is causing this? Any solution?
-
The solution is to wait for Steven to take a look at it to see if it can be fixed. I remember a time a good number of years ago, before MB had a wavebar and the progress bar was a second or so out of sync with the actual music. Steven fixed that, so perhaps he'll be able to fix this. There's nothing you can do other than being patient.
-
Ok, thanks! I'm good at being patient! ;)
I only want to make sure that Steven is aware of this problem...
-
1 seconds seems quite a high latency but in any case this version should adjust for that if you are using WASAPI (shared)
https://getmusicbee.com/patches/MusicBee33_Patched.zip
unzip and replace the existing musicbee files
-
Unfortunately there's not much of a change. Or there is and it's worse. On some tracks the lag is 3-4 seconds.
Using WASAPI (shared) with bluetooth headphones or with speakers connected directly to the speaker port of the sound card. I also tried DirectSound with both output devices and there's no difference.
Would my settings file be of any help?
-
when you start playing music, is there a 3-4 second lag before you start hearing the sound?
Also are you using any Equaliser/ DSPs ?
-
when you start playing music, is there a 3-4 second lag before you start hearing the sound?
Also are you using any Equaliser/ DSPs ?
No, there's no delay between the sound and the wavebar position when I first start playing a track.
I do have the Stereo Enhancer DSP enabled, but I tried with it disabled and I see no difference.
-
in that case can you send me a link to your settings
-
PM with link sent.
Thanks.
-
could you also send me one song where you see the 3-4 second lag and also post a screenshot so i can compare with my computer?
-
PM sent with link to track and screenshot.
-
The reason is due to the way BASS processes MP3 files (it approximates the seek points in MP3 files). If you convert the file to flac, it will be spot on.
There is a setting in BASS that mostly addresses the issue but it substantially increases the load time to open the mp3 file, so I dont want to implement that for what in my view is not a serious issue.
I think the inaccuracy is mainly with large MP3 files as the player position approaches the end of the track. I have made one change though - when you jump position using the seek bar, it now makes use of the BASS flag i was referring to, and is accurate in my tests for the file sent.
https://getmusicbee.com/patches/MusicBee33_Patched.zip
-
As a test, I converted the file to FLAC and I agree - it's spot on. I also tested the original track (which I sent you) and it's much better - especially near the end of the track.
As a further test, which I will do later today or tomorrow, I will test tracks with smaller MP3 files and report back.
Can you confirm that it's a waste of time and disk space to convert a lossy format to a lossless format, especially for a relatively minor,
mostly visual problem?
Thanks for looking into this and for the explanation as to what is going on.
-
Actually i think the last patch version should completely solve the issue. See how you get on
-
Actually i think the last patch version should completely solve the issue. See how you get on
Played some long tracks and played some short tracks. I feel the result is pretty consistent no matter what the length. While it's not spot on as it is/was with FLAC files, the MP3s are off by what I'd guess is less than a second. Which is certainly acceptable as compared with what was happening before you looked into it.
Thanks. And hope you have a happy, healthy, and successful 2019.
-
@Steven...
I hate to bring up an issue from last year that I though was resolved, but on MP3 tracks that I don't consider all that large, I'm seeing a 2-3 second lag between the wavebar current position and the actual sound. I've noticed this over the past 3-4 builds, but I can't imagine you did anything to change it. Currently on 3.3.6952.
If it turns out it's the best it can be, I'll have to live with it, but if some more tweaking can be done, that'd be great.
I'm going to PM a link to a track that, at least to me, it's quite apparent.
Thanks.
-
Where in that track are you finding a 2-3 second lag? And are you using the seek bar at all, or letting play reach the position normally?
For me, a couple of places seem to have a 0.5 second lag but i cant find any large lags
-
There's a 2+ second lag at the following points:
0:03
0:12
1:24
2:52
It seems obvious to me. Look at the peaks on the wavebar. I'll look for a track that had a greater lag when I was listening last night.
-
the 0:03 point is a good one to focus on.
I will compare the graph to audacity to make sure its in agreement the blip is at 0:03
I guess you are saying you actually hear the sound when the progress bar says 0:05?
for the record i hear it and see the progress bar at 0:03
Also could you confirm you have no DSPs active and the same behaviour when WASAPI (exclusive) is used?
-
the 0:03 point is a good one to focus on.
I will compare the graph to audacity to make sure its in agreement the blip is at 0:03
I guess you are saying you actually hear the sound when the progress bar says 0:05?
for the record i hear it and see the progress bar at 0:03
Not quite. I -hear- it at :03 but the vertical progress indicator reaches that point when the sound is at :05. The 'indicator' is running ahead of the sound.
Also could you confirm you have no DSPs active and the same behaviour when WASAPI (exclusive) is used?
I did have the Stereo Enhancer" enabled, but I see the same issue with it disabled.
-
I compared the graph with audacity and its the same graph. The exact position in audacity is 3.75 seconds.
There is some rounding involved with the position of the MB graph bars depending on the overall width of the progress bar, and also MB rounds the displayed progress position up, so there is some scope for discrepencies due to rounding.
Having said that, I hear the blip at 3-4 seconds and see the same on the progress bar. I think I will need to leave it unsolved for you
-
Having said that, I hear the blip at 3-4 seconds and see the same on the progress bar. I think I will need to leave it unsolved for you
Ok - thanks for taking the time to look at it.
-
I hope this is the right thread. I am listening to my bird sounds on musicbee, mp3 some 10-30secs long. the chirps from the birds don't match up to the waveforms as it progresses. Also with the shorter files using crossfade the last 5 seconds is clipped off of a 12 sec or so file. I have the same problem with poweramp. I guess the crossfade doesn't' adjust for the shorter files.
-
@Steven-
Would you be willing to take another look at this in the near future? I can PM you the link to two tracks (one short @ 44 seconds, and another average length @ 3:11.
This issue is so readily apparent to me that I'm almost ready to abandon the wavebar. Which I really don't want to do.
Thanks
-
@Steven-
Would you be willing to take another look at this in the near future? I can PM you the link to two tracks (one short @ 44 seconds, and another average length @ 3:11.
This issue is so readily apparent to me that I'm almost ready to abandon the wavebar. Which I really don't want to do.
Thanks
Just curious and offering, if it helps, send me a link to the files and I can let you know what I experience with my setup/hardware?
-
Yes, and I may add: what is the difference between foobar2000 decoder and musicbee decoder? Because in foobar2000, the wavebar is always accurate.
(But I prefer musicbee, so I would like to have best of both worlds...)
-
Just curious and offering, if it helps, send me a link to the files and I can let you know what I experience with my setup/hardware?
I'll accept your offer with thanks.
PM sent.
-
I have been consciously aware of the wavebar not being synchronous with the sound for a long time, but it hasn't bothered me enough to raise/support issues with it.
But that is probably because I usually have the wavebar positioned very small in the sidepanel.
For this testing I enlarged it, and the discrepancy is now very clear to notice.
I am guessing I have the sound trailing the wavebar approximately 0.6 seconds, which is a lot indeed.
It would bug me for sure if I had the wavebar larger then the some three inches I usually have it at.
(nice music b.t.w.)
-
Thanks for giving it a shot. Since my wavebar spreads across the entire bottom of the window, it's -very- apparent. Maybe this will help Steven if he takes another look at it. I should add that the delay is off by under a second. Which is a lot with a wide wavebar.
I will add that I installed Audacity and while not spot on, it's much closer than with MB.
Glad you liked the music.
(http://i.imgur.com/nV5npmfl.jpg) (https://i.imgur.com/nV5npmf.jpg)
-
Yes, and I may add: what is the difference between foobar2000 decoder and musicbee decoder? Because in foobar2000, the wavebar is always accurate.
Foobar uses a combination of its own internal decoder and modified ffmpeg libraries depending on the file type. MusicBee uses the extensive and constantly updated BASS audio libraries. AIMP, which you mentioned in another post, uses BASS decoding libraries (and ffmpeg for webm and some alt. types) in combination with its own engine which internally supports wasapi/asio/DS outputs and does its own resampling. That is just FYI per your question, what it may or may not have to do with the wavebar sync I do not know.
-
Thanks for giving it a shot.
Not sure, and just an observation in the spur of the moment: this seems to have improved with one of the latests updates?
-
Not sure, and just an observation in the spur of the moment: this seems to have improved with one of the latests updates?
A very quick test with .7086 doesn't seem like it's changed any. I'll have more time tomorrow to find a better track to test it.
Thanks for the heads up.
-
Still showing a lag. The audio occurs after the wavebar.
This is the file I'm using as a test. Obviously the -visual- is exaggerated with such a short (50 seconds) track, but the time difference is about the same with a longer track - a little over one second.
https://www.mediafire.com/file/y272rs3o2meo3zz/Snowy_Day_Test.mp3/file
-
Still showing a lag. The audio occurs after the wavebar.
You're right.
I'm sorry, I was playing a long classical track, and it caught my eye that the progress seemed better synchronized.
-
I'm sorry, I was playing a long classical track
That's what you get for listening to classical. You need some good ol' rock 'n roll. THUMPA THUMPA THUMPA
-
i will have another look at some point in the future but it will be helpful if its confirmed if converting to flac format solves the issue
-
Thanks Steven. Converting to flac doesn't improve it. On my first two tries with flac, it almost seemed slightly more exaggerated. But if in fact it was, it was only by milliseconds. I appreciate that you're willing to take another look at this in the future.
Do you want the flac copy?
-
Thanks for the test file
I am comfortable that the wavebar values and the display of the wavebar is accurate and visually comparable to audacity.
After some more testing i have come to the conclusion its simply a delay between when the sound data is proceesed and when you actually hear it. For example, playing using ASIO, there is no latency and the sound plays exactly according to the wavebar, but any other output mode there is a delay of approx 250ms.
So I have put in a display delay of 250ms, however I am uncertain that will be the same for all machines as i believe its more than just the internal buffering that BASS uses
https://getmusicbee.com/patches/MusicBee33_Patched.zip
-
So, obviously it's gonna be hard to adjust to accommodate for every setup.
Just in case it is useful info: with my setup (wasapi exclusive, play some silence, event mode) I now have some 0.3 seconds delay between audio and visual.
-
how about when using WASAPI (Shared) and also WASAPI exclusive without event mode ?
edit:
the next update should address wasapi event mode, but if you could verify the other 2 modes then that would be helpful
-
Maybe better ignore my previous comment...
A quick re-test now implies the opposite, namely the progress bar slightly trailing the audio. That's new.
When I have a clear head and more time/concentration I'll see if I can come up with some coherent info that may perhaps be more useful.
-
https://getmusicbee.com/patches/MusicBee33_Patched.zip
-
When I have a clear head and more time/concentration I'll see if I can come up with some coherent info that may perhaps be more useful.
This is not the clear-headed analytical response yet, but I did notice something very odd I thought to mention:
I tested one track that is now right on the money. (using both an mp3 and a flac rendition)
But I tested another track where the audio trails the visuals substantially. As a rough guess at least half a second. (both flac and mp3)
So it looks like there is a whole different factor at play here that has an influence.
(perhaps embedded metadata, albumart?)
I'll do some more testing, perhaps tomorrow.
-
With the update in Reply #44 I'm finding that it's close enough that I can live with it. There is still a very slight lag on just about every track I tested. But not enough of a lag to spend more time on it for me although hiccup seems to have issues. I'll wait for his more thorough testing.
BTW, I'm using WASAPI shared. I have no ASIO device so I tested on Direct Sound which to me seemed as close as WASAPI shared.
There were (are) two tracks that are more 'off' than everything else I tested today. But I'm not going to worry about a random track here and there. Although I would think if it's fixed for the bulk of them, why would it not be for these odd ones?
-
I must say that with the latest updates I'm pretty satisfied too. I use WASAPI shared, and every file I listen to is "accurate enough" since today's updates. Thanks! :)
-
@phred, can you also try with WASAPI exclusive?
-
The exact same track that yesterday clearly trailed a lot (some 0.7 sec) both as mp3 and as flac, now play pretty much spot on.
No changes to audio settings, just a pc restart.
I'm putting this on ice.
-
The exact same track that yesterday clearly trailed a lot (some 0.7 sec) both as mp3 and as flac, now play pretty much spot on.
No changes to audio settings, just a pc restart.
I'm putting this on ice.
i am not sure whether you saw my comments and are using the updated version which made some changes for event mode
-
i am not sure whether you saw my comments and are using the updated version which made some changes for event mode
I used the latest patch 3.3.7091.36867
Since I didn't change settings between yesterday and today, and now both songs play fine, there must have been some glitch I can not explain.
To repeat myself for clarity, yesterday song A played fine, both mp3 and flac, but track B trailed some 0.7 sec., both the mp3 and the flac version.
Today all 4 versions play well.
Since I can not replicate it today, I don't have much to contribute to this further, and I am gonna put the wavebar in the small corner where it used to live before, and where any discrepancy never bothered me.
-
@phred, can you also try with WASAPI exclusive?
WASAPI exclusive seems to be closer than WASAPI shared. But if it actually is, it's only by micro-milli-seconds. Barely detectable difference.
As stated yesterday, I'm willing to put this to rest. Unless it pops up again in the future.
Thanks for plugging away on this, Steven.
Somewhat related question - why would/should I use WASAPI exclusive rather that shared? There are time where I'm playing something in MB (shared) and stop the playback and check out something online. As I understand it, I'd have to shut down MB exclusive in order to hear audio from another source. Is that correct?
-
Somewhat related question - why would/should I use WASAPI exclusive rather that shared? There are time where I'm playing something in MB (shared) and stop the playback and check out something online. As I understand it, I'd have to shut down MB exclusive in order to hear audio from another source. Is that correct?
Here's what Steven said on another thread about it a few months ago:
WASAPI (Shared) and DirectSound are different APIs that both use the same windows processing via the Windows Mixer.
The advantages are for the functionality available to developers.
However some exernal applications and Linux Wine need the DirectSound API to be used in order to function
You don't need to shut down MB to hear audio from another source, you just need to stop (rather than pause) playback in MB when you want to.
I hear a pretty significant improvement in sound quality using Exclusive over Shared, and I'm not particularly "golden eared.".
-
Don't put any more effort on this on my account, but the issue was still in my head, and while playing a very short track I noticed the waveform was completely off.
Doing a test with very short tracks seems to show that short tracks can have some weird waveform issues.
(Which might explain what I experienced yesterday with what was also a short track, approx 30 seconds.)
In case anybody's interested and wants to try it out, here are two tracks that on my system don't even come close in matching audio/waveform progress.
https://www.dropbox.com/s/o3k0d0fw2ok6yvd/short%20test.rar?dl=0
Anyway, since for more 'normal' length tracks it seems there is not really an issue anymore I can understand if this case is closed.
-
Thats due to the very short length and presumably wide wavebar you might have - the returned graph data doesnt correctly represent the actual values. There are some limitations on the bass decoder that makes handling that situation more difficult but i will see what can be done
-
actually it was quite easy to fix:
https://getmusicbee.com/patches/MusicBee33_Patched.zip
-
Nice, another mystery solved.
The 30 sec track now also plays tight every time.
-
I hear a pretty significant improvement in sound quality using Exclusive over Shared, and I'm not particularly "golden eared.".
Ditto that here. Also, since Exclusive by-passes the Windows mixer, the sample rate of the original file is passed directly to the device instead of being resampled to match the sample rate set in Windows. As long as your audio device/card is compatible with the source sample rate, that is the rate at which it will be played, regardless of the Windows setting. With the BASS library, if the source rate is NOT compatible with your device (which means that in Exclusive the playback would fail), bass.dll itself will resample to a compatible rate (44.1kHz in my experience). That very rarely is necessary with modern devices which accept a wide range of source sample rates.
-
There now often appear some artifacts in the waveform:
https://i.imgur.com/BSrz3Iq.gifv
(likely a consequence of the latest waveform fix)
-
@frankz & sveakul...
Thanks to both of you for the clarification of shared vs exclusive. I did a couple of quick tests as you've removed my concerns about not being able to output from another source. I assume in the past I paused and not stopped. Stopping allows me to do what I thought I couldn't.
-
There now often appear some artifacts in the waveform:
that should be fixed now
https://getmusicbee.com/patches/MusicBee33_Patched.zip