Kodi Community Forum

Full Version: Issue with musepack playback (first part cut off)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi all,

I am still owning several old musepack files and would like to play them via kodi on my HTPC. Until now I did not add them to my library as kodi shows an annoying issue with the playback: the first part of a track is cut off -- e.g. the first note of guitar riff or a drum hit is missing. As I can observe this with several tracks I assume it is an always-issue with each track. Other players like foobar or mpd do not show this problem. I never measured the exact length of the missing segment, but would estimate it to be about 0.5 seconds. The removal of the APEv2 tag does not impact this behaviour.

Is there any chance that this can be reproduced or even fixed?

Best wishes,
I have no idea what a musepack file is, and so no way to test etc. Also what version of Kodi are you using?

If you would like to turn on debug logging and provide a log file debug log of playback of one of these files then that could be a starting point. You probably also need to provide the file that can reproduce this.

Then I will need to ask one of the player experts to take a look.

thanks for the quick response. musepack is an open source lossy audioformat which files typically end with ".mpc". I will read through your link and provide the logs.

If needed I also can provide a file for reference.

Hi again,

link to the logs: http://ix.io/12Cb

Btw, the issue is also present on a kodi 17.6 and kodi 15.2 installed on Linux.

The consensus is that muse pack files generally play in Kodi. If ffmpeg (the decoder used by Kodi player) is having difficulty your particular files then an example file is needed. Also v17.6 is frozen, with all dev work going into v18 including a much newer version of ffmpeg.

My suggestion would be to install a recent v18 nightly, and try playing those files. If the issue persists with v18, then provide a new debug log and an example file. However be warned dev interest in getting old formats like muse to play in Kodi is limited - there is much work to do, and few devs to do it!

Another way forwards would be to convert the muse files to flac, perhaps this would be a better approach.
Hi again,

thanks for your response. As you suggested I downloaded and installed latest nightly build and reproduced the issue (first playing a file with metadata tag, followed by a file without such tag). I uploaded the logs and the musepack_test_files. When using ffmpeg (ffmpeg version N-90518-gaf043b839c) to decode the files to wav they are properly decoded and dont´t miss the first part of the file.

Let me know if I can be of further assistance.

Thanks for your enthusasm, I'll ask our ffmpeg experts to take a look (it is all beyond me) when they have time.
Are you the Buschel of Hanover, well-known for drinking lots of beer and coffee during our studies at TNT ?

Greetings to Karlsruhe, MB
@Dave: https://www.musepack.net/
Well, I do not hope I was only well-known for this. But, yes, that´s me. Smile
Maybe you could contact me via private message. Hope this works as I cannot start a pm from my side (yet).
Hi all,

today I played around with building Kodi (kodi 17.6, ffmpeg 3.1.11) and also reviewed the ffmpeg source code for musepack. I now found a way to work around the issue, but this needs some more debugging and deeper understanding of how the codec API is used.

Workaround: Comment the code within function mpc7_decode_flush() in libavcodec/mpc7.c, in detail only the line "c->frames_to_skip = 32;" must be commented.

Pro: No loss of the first 32 frames when decoding musepack SV7 files.
Con: Weird noise for 32 frames when jumping to another position within a SV7 file.

Reason: Musepack SV7 uses differential coding of scalefactors. Each 32 frames the bitstream is providing an absolute value again. So, when seeking/jumping to a specific time position you need to decode 32 frames before you have the proper scalefactors for synthesizing the signal. I assume the "flush()" function was added to mute the signal for 32 frames when jumping to time positions. This type of muting must not be used when simply starting to decode a file from start. In the current Kodi implementation it seems that flush() is also called when starting to decode a file at position 0.

1. If target frame pos <=first 32 frames: do not reset dscf data, frames_to_skip = target frame pos.
2. If target frame pos > first 32 frames: reset dscf data, frames_to_skip = 32.

Question: How is kodi making use of flush()? Is kodi using something like "jump-to-0 and flush" before starting to decode each file? Can you point me to the file where the calling function is implemented?

I have some *.mpc files and they play perfectly fine in latest KODI. As @DaveBlake politely pointed out, older versions of Kodi than v18 will not be fixed.

Also, *.mpc is a lossy format so please don't convert to *.flac as that generates a fake lossless file. The music community frowns upon that kind of thing should the files ever be passed on.
Hi again,

I just retested with Leia 8.1 (Release) on Linux Mint 19.1 installed from the ppa and the issue persists. Please remind that the issue is only audible if the audio track starts right away as only the first 32 frames (0.8 s) are missing. As an example you can use the following test track: https://www.sendspace.com/file/xju086. Properly decoded the tracks starts with the singer breathing in (can be checked with any other mpc supporting player). Kodi misses this breathing sound and starts with the first words of the singer. It is very obvious.
The simple proof-of-concept code change to fix the playback is applied to libavcodec/mpc7.c is to just comment one line:
Quote:static void mpc7_decode_flush(AVCodecContext *avctx)
    MPCContext *c = avctx->priv_data;

    memset(c->oldDSCF, 0, sizeof(c->oldDSCF));
    /* c->frames_to_skip = 32; */

I will try to download and compile headrevision tonight and apply the same fix. In the meanwhile it would be helpful if someone can help me with pointing me to the right place from where the seek is triggered and the decoder functions are called.

(2019-04-19, 07:48)Buschel Wrote: [ -> ]Kodi misses this breathing sound and starts with the first words of the singer.

You are right, I apologize. It is obvious after comparing.
No worries. In the meanwhile I could verify that the code change I posted above has the same effects on the latest sources from the Leia branch:
1. Good: Playback starts correctly from the start
2. Bad: Weird noise for the first 0.8 after seeking.

I am not used to the ffmpeg code and have some difficulties understanding the way seeks are performed. Best would be to find a simple way to not call flush when seeking to positions <1 s from the start of the file.
While listening to some music yesterday in party mode, I seemed to observe this behaviour with other formats as well. It's hard to notice while listening casually since the cutoff is very short. I will need to make some dedicated comparisons.
Pages: 1 2