theiceberg Posted June 30, 2019 Share Posted June 30, 2019 Hello, I'm using a Galaxy S8 and pretty much since switching to v3 months ago I've been encountering this weird track drift that's obvious by observing the 0:00/-:-- info for the song. Messed around with it a bit, can easily recreate this by force closing and reopening the app, each time doing this the song advances a fraction of a second. Not sure if this is a true bug or a strange way one of the crossfade settings behaves with a restart. Either way figured I'd point it out. Here's a probably passable visual of what I'm talking about: https://photos.app.goo.gl/RVzXKyNjQp8Tirto7 Thanks Link to comment Share on other sites More sharing options...
andrewilley Posted June 30, 2019 Share Posted June 30, 2019 Seek accuracy varies a bit by file format, and without rendering the whole track (quite time-consuming and processor intensive) it's hard to do very much about it - especially if the header data does not contain any seek helper (TOC) information. The worst cases are some VBR MP3 files, I've had the seek to save-point accuracy on very long podcasts (such as two hours or more) drift by as much as a minute or two near the end. Andre Link to comment Share on other sites More sharing options...
maxmp Posted June 30, 2019 Share Posted June 30, 2019 Some tracks can’t be easily sought to the desired sample. They can be sought to the desired sample when they are decoded from the beginning, but this is not an option for mobile device (imagine seeking podcast 2hours mp3 - too much stress for battery and overal slowdown). Mp3 can have seek table, this helps, but still is not accurate and sometimes - broken. If you think the particular file seeking is unacceptable, please provide a link/share via player / Send / Gmail / gpmaxmpz@gmail.com - I’ll test it and may be add some workaround for the particular case. Link to comment Share on other sites More sharing options...
theiceberg Posted June 30, 2019 Author Share Posted June 30, 2019 Thank you for your replies, I appreciate the explanations. It's definitely not a deal breaker, I moreso wanted to understand what was going on here. Potentially long efforts to sort out something like this is a bit more time consuming than just restarting the track, so I'll manage the quirk. Thanks! Link to comment Share on other sites More sharing options...
andrewilley Posted July 1, 2019 Share Posted July 1, 2019 On 6/30/2019 at 9:30 AM, maxmp said: If you think the particular file seeking is unacceptable, please provide a link/share via player / Send / Gmail / gpmaxmpz@gmail.com - I’ll test it and may be add some workaround for the particular case. Did you great round to taking a look at the one I mentioned a few months ago, which is pretty long and exhibits this issue very markedly? I'm sure there will turn out to be no Seek table in the file, but it might be worth taking a look in case you can do anything to improve these sort of cases. http://traffic.libsyn.com/alohomora/Alohomora_Cursed_Child_NYC_Earth_One_and_Earth_Two.mp3 .Trying to save/restore a playback position near to the end of this file can drift by minutes at a time. Andre Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.