Fixing bit-rate calculation, thus fixing 'duration' and 'progress' parameters for long files #95
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Precision was lost when summing up all the bit-rates together and then dividing it with the count in the -calculateBitRate method. So the bit rate looses couple hundred bits, and thus shows wrong duration for long files, also give wrong progress.
Can be tested with this 60 minute voice sync file given below, run it on VLC or some other player, its total duration is actually 1 hour 36 second, but without the fix of bit-rate, it shows 1 hour 56 second or something. And after every seek, it shows some extra seconds as current progress.
Also added a small method for break down the seconds to HH:MM:SS so that we can take a better look at duration and progress time.
Download the test file from here: https://www.dropbox.com/s/lwg8o42hkpweoxw/60minSyncTest.mp3?dl=0