Skip to content

Conversation

@mattgarrish
Copy link
Member

@mattgarrish mattgarrish commented Mar 21, 2022

I've added a tolerance to the recommendation per the discussion in #2093. I've also added a note to explain why we have this tolerance.

This is probably another to take to the WG to discuss before merging, though, since it changes the recommendation.

Fixes #2093


Preview | Diff

@avneeshsingh
Copy link

+1 to indicate tolarance for rounding off errors.
In DAISY validators (original version of Media Overlays), I usually used 30 to 50 millisecond of tolerance.
My question is if the tolerance should be part of normative specs. Or should we provide an informative note that plus minus one second tolerance is allowed.

@iherman
Copy link
Member

iherman commented Mar 22, 2022

My question is if the tolerance should be part of normative specs.

I believe it is cleaner. Otherwise, it becomes an RS or checker dependency and possibly an interoperability issue.

I cannot comment whether it should be 1sec or less. For a layperson like me, 1 sec seems to be enough, because it is just a global indication for the RS. But I leave this to experts.

@mattgarrish
Copy link
Member Author

mattgarrish commented Mar 22, 2022

Otherwise, it becomes an RS or checker dependency

Right, and this is what causes complaints in the epubcheck tracker. If we don't formalize in the specification, then we open the door to people demanding other tolerances or no tolerance.

I usually used 30 to 50 millisecond of tolerance.

This is why I suggested we should discuss on a call before accepting this PR. Like Ivan, I'm not sure what specificity most authors/tools use, so I'm not sure how big a discrepancy we might get. Over 100+ files of Moby Dick, for example, small rounding differences could add up, but to what I'm not sure.

It's easy enough to adjust the tolerance from this default.

@wareid wareid added the Agenda+ Issues that should be discussed during the next working group call. label Mar 23, 2022
Copy link
Member

@rdeltour rdeltour left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, pending the approval of the default tolerance threshold by the WG.

@iherman
Copy link
Member

iherman commented Mar 25, 2022

The issue was discussed in a meeting on 2022-03-25

List of resolutions:

View the transcript

1. Tolerance margin for the sum of MO durations? (issue epub-specs#2093)

See github issue epub-specs#2093.

See github pull request epub-specs#2106.

Dave Cramer: we say the sum of the duration for each MO document should equal the total duration, but we've never specified a margin or tolerance for this.
… suggestion was that perhaps we should do so?.
… the suggestion was to allow 1 sec of tolerance before epubcheck would complain, to account for rounding errors.

Avneesh Singh: I think this is not controversial.

Ivan Herman: what I learned when I made tests, is that this value which is in the manifest is there to check the data.
… marissa has even suggested that this is unnecessary.

Ivan Herman: I can't say whether or not that is so, but if it is just for checking purposes, then allowing some rounding error is fine.
… not sure what the actual threshold should be, so for now I think 1 second is fine.

Zheng Xu (徐征): from what i've implemented, the duration is variable for different players on different platforms.
… so i wonder if this is even useful.

Avneesh Singh: regarding 1 second, i feel this is more than enough. Maximum 50 ms is what i've used in the past.
… for large audios (120 hours), a tolerance of 150 ms was enough.
… per my understanding, the purpose of stating this metadata is to allow RS to pull a "total duration" value into features like "you are 5 minutes into 12 total hours".

Brady Duga: can epubcheck just tell you the total duration value that should be in the manifest?.
… epubcheck can give you the right value, right?.

Matt Garrish: epubcheck is checking the total time, yes. I guess it could output that value..

GeorgeK: my recollection is that its difficult to calculate some of these things precisely, depending upon the compression that is being used, resulting in it being off by a smidgen in each file.
… so this type of tolerance seems absolutely fine, 1 second seems fine.

Ivan Herman: +1 to George.

Zheng Xu (徐征): as a RS I appreciate having the duration values for the whole book, and for each file.
… we use it as an indication of approximately where the user is, but it doesn't have to be that accurate.

Dave Cramer: i'm not hearing an argument against the 1 sec tolerance.
… it's obviously a useful piece of metadata for people reading the book.
… and having epubcheck able to tell if the sum = total is useful authoring tool, with 1 second tolerance.

Zheng Xu (徐征): +1.

Ivan Herman: +1.

Proposed resolution: Merge PR 2106, close issue 2093. (Wendy Reid)

Dave Cramer: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Wendy Reid: +1.

Laura Brady: +1.

Avneesh Singh: +1.

Bill Kasdorf: +1.

Ivan Herman: +1.

GeorgeK: +1.

Zheng Xu (徐征): +1.

Ben Schroeter: +1.

Resolution #1: Merge PR 2106, close issue 2093.

Rick Johnson: +1.

@iherman iherman removed the Agenda+ Issues that should be discussed during the next working group call. label Mar 25, 2022
@iherman iherman merged commit 71dc9ab into main Mar 25, 2022
@iherman iherman deleted the fix/issue-2093 branch March 25, 2022 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tolerance margin for the sum of MO durations?

7 participants