Posts: 1,159
Joined: Mar 2018
Reputation:
26
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,
Buschel
Posts: 1,159
Joined: Mar 2018
Reputation:
26
Hi,
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.
Best,
Buschel
Posts: 4,545
Joined: Jun 2015
Reputation:
269
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.
Posts: 4,545
Joined: Jun 2015
Reputation:
269
Thanks for your enthusasm, I'll ask our ffmpeg experts to take a look (it is all beyond me) when they have time.
Posts: 1,159
Joined: Mar 2018
Reputation:
26
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.
Solution:
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?
Regards,
Buschel
Posts: 1,159
Joined: Mar 2018
Reputation:
26
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.
Posts: 1,234
Joined: Mar 2011
Reputation:
80
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.