Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: ilikedirt on June 18, 2008, 09:58:57 PM
-
Hi,
I stumbled accross a glitch with a certain Musepack file. A loud "blip" sound appers on certain times in this file when played back with Rockbox (latest build r17732 as well as older build from 2008-05-19). The same file plays back in foobar2000 just fine. I dont know if more files are affected. If someone is interested I could send the file for examination.
-
Theres been a lot of changes to MPC in the last two months. Trying a build from mid or early April would be interesting.
-
Is there a place where I can find builds older than one month? Or can someone upload one for me? That would be somewhat easier for me than setting up the build enviroment myself - appart from me not beeing familiar with using it.
-
Is there a place where I can find builds older than one month?
Nope - 1 month is all we keep.
Or can someone upload one for me? That would be somewhat easier for me than setting up the build environment myself - apart from me not being familiar with using it.
Possibly someone can - but it might be worth the trouble of learning how to do the building - it's not as tough and scary as it looks!
-
I build r16903 from April 1st. The glitches on my file are already there.
-
Hi,
is there any possibility get this file for further debugging? I have an idea about this issue...
Buschel
-
Hi Buschel,
of course. How would you like me to send you the file, email? You could PM me your adress.
-
hi,
should be solved with r17829. the (already present) hack never seemed to work correctly due to the wrong default scalefactor.
musepack uses differential scf-coding in time domain. if you decode from the beginning everything is fine. if you seek with in a file, the decoder may not know the reference-scf after seek -- in the file i've tested this happened with highest subband. in this case the decoder uses a much too high scf what results in burst noise. solution (or better hack) is to use the lowest scf (equals fading out of the subband) until there was a reference scf decoded (1st non-differential coded scf).
please report, if the problem is solved now.
thanks,
buschel
EDIT: The bug is reported as fixed with r17829.