[billy_04]

FernetMenta,

You aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaare defenders of the faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaith !!!

All my (mp3) samples played perfectly with this build. The start-stop-advance issue I was having with the previous test builds also vanished (coincidence or not)...

I am currently enjoying lots of gapless albums as I type this...

So, is it safe to assume you found a 'problem' and corrected it? If so, will we have to wait for the 15.0 stable release to enjoy it, or will it be back-ported to 14.1, 14.1.1, 14.2 etc.?

[FernetMenta]

glad to hear that it works.
as I said, this is only a 2-lines change and I see no issue picking it for 14.2

[jac55]

"best match" is not wise choice if you want to enjoy gapless. I have mentioned this many times but somehow the info disappeared from the help text and the wiki. Audio engine might need to reconfigure due to different parameters required for the next track.

If the audio setting is set to optimised then if a 16/44.1 track is queued to play first followed by a gapless album which is 24/96 I believe that album will be resampled. Is there any way to maintain bit perfect and gapless in such an example?

For music playing I like to use the best match setting but I also want to maintain gapless playback. I have mentioned this before in another thread somewhere. I cannot think of any instances where gapless playback is necessary if the sample rate or bit depths are different for the next track because gapless is only meaningful for an album where the music flows from one track into the next, like in the Pink Floyd album Dark Side of the Moon, and it is highly unlikely that the tracks of a gapless album will include different sample rates and / or bit depths.

So I believe it is OK to relegate priority for gapless playback between the first track and the next, and give priority to reconfiguring the audio engine even if this takes a bit of time getting ready for track 2 which is the first track of the album which actually requires gapless playback thereafter.

I hope I have managed to get my point across. If it is unclear I will try and explain a bit better.

[jjd-uk]

You are correct if you have a playlist where the 1st playlist track is 16/44.1 and the 2nd playlist track is 24/96 track and that is the start of an album (so 2nd track of playlist is 1st track of the album) then you need to use Best Match to prevent resampling of the 2nd playlist track however this will introduce a gap, but then each subsequent track of the album (assuming they are all 24/96) will then be gapless I think.

[billy_04]

On my system, the mp3 gaps have returned/persist with the release candidate most recently posted (14.2-RC1, March 11, 2015).

Please see http://forum.kodi.tv/showthread.php?tid=...pid1958069

[billy_04]

bump?

[jjd-uk]

As far as I can the fix is in 14.2

Are you able to test a nightly to see if it's an issue there? If you install into a different folder and run in portable mode then it won't affect your existing install.

@FernetMenta any ideas what might have happened?

[billy_04]

Kodi 15.0-Alpha1 (Built Februrary 28, 2015) works correctly (no gaps or ticks).

As per the suggestion, I just tried the latest nightly (15.0-alpha2 git:20150320-ada3a4b) and it also works correctly (no gaps or ticks).

14.0, 14.1, 14.2RC1 all have gaps and / or ticks...

[billy_04]

In the spirit of trying to be helpful... I have done a virgin KODI 14.2RC1 (running in portable mode) reload and have not had any success in getting consecutive mp3 files to play without gaps.

A debug log can be found here -> http://goo.gl/bd3heG

I have tried all the previous suggestions, as well as switched between DirectSound and WASAPI and the options of best match, optimized and fixed (44.1 & 48) to no avail.

13.2 works correctly, as do the alpha builds of 15 (foobar and Winamp also work correctly). No version of 14 will play without a gap or tick between what should be seamless tracks from the same album and rip.

I am dreading the impending release of a 'stable' 14.2 that I can't use and will have to wait until 15 before moving on from XBMC 13.2...

Any advice, confirmation or comments appreciated.

[jjd-uk]

I'll try again @fritsch @FernetMenta any ideas?

[billy_04]

Onward toward 15...

[FernetMenta]

I'll try again @fritsch @FernetMenta any ideas?

the fix is only in master https://github.com/xbmc/xbmc/commit/c50f...2cb0de485f

[jjd-uk]

I'll try again @fritsch @FernetMenta any ideas?

the fix is only in master https://github.com/xbmc/xbmc/commit/c50f...2cb0de485f

That's part of this merged into Helix branch I thought https://github.com/xbmc/xbmc/pull/6419

[FernetMenta]

you are right. no idea what is wrong with 14.x

[jjd-uk]

No matter, at least Isengard shouldn't be far off if we stick to schedule.