INTERACT FORUM
Devices => Apple iPad, iPhone, iPod, Airplay => Topic started by: glynor on March 01, 2016, 09:42:08 pm
-
I was posting over here (https://yabb.jriver.com/interact/index.php?topic=103482.msg719366#msg719366) about streaming audio with JRemote. And an accidental, and fortuitous screenshot coincidence made me realize there is a bug in how JRemote displays time remaining when streaming a transcoded file (at least when using the MP3 Medium setting). Check it out:
(http://glynor.com/img/screenshots/JRemote/JRemote-Transcoding_Example-small.png) (http://glynor.com/img/screenshots/JRemote/JRemote-Transcoding_Example.png)
Both screenshots were taken at basically exactly the same moment during playback: with 4 seconds elapsed (again, not because I'm a perfectionist, it was an accident).
The non-transcoded one shows the correct time remaining of -2:33 (the file duration is 2:37).
The transcoded one shows -2:41 which is, well, wrong (and is longer than the total duration of the file). It's off by 8 seconds (2:41 + 0:04 = 2:45, which is 8 seconds longer than the duration of the track).
I was chuckling about the coincidence, and then noticed that while elapsed time matched perfectly, the time remaining didn't. I've subsequently checked several other FLAC files in my Library, and they're all wrong when transcoded. And, always by 8 seconds.
-
Funny way to find a bug. You could add the "32bit" value of the MP3 to the bug ;D
Could it be VBR related (read about this somewhere and the problems of MP3/AAC file structures, streaming and chapters) and the 8s is a result of a specific sampling rate?
-
There is definitely something odd with mp3 conversion. http://yabb.jriver.com/interact/index.php/topic,107121.msg748825.html#msg748825 (http://yabb.jriver.com/interact/index.php/topic,107121.msg748825.html#msg748825)