TOC specifying a single chapter over multiple files

[LFriedenthal]

I see in the spec how the TOC handles media fragments within a single file.
I see publishers much more often splitting chapters across multiple files, though. Is there a proposed solution for communicating this in the TOC in a way that produces only unique TOC entries?

I have a lot of books being sent to us right now that even if they were packaged as an LPF would have a TOC like:

Opening Credits
Chapter 1
Chapter 1
Chapter 2

Because they've cut Chapter 1 into two mp3s "for time" or on some arbitrary length limit. (And some other retailers do have hard chapter runtime limits, so they require you to cut chapters up.)

[wareid]

Excellent question, we did consider this and ran into issues with how to best address it.

I think our hope was that reading applications would have the sense to condense files into single lines if they had the same title, but not sure how successful that might be.

Hopefully we can stir some conversation!

@danielweck @marisademeglio @bduga

[danielweck]

Hello, I don't understand why the TOC contains two links to chapter one, in your example. The publication's reading order may indeed reference as many physical audio resources as needed (e.g. chapter1-a.mp3 followed by chapter1-b.mp3), but the TOC is meant to be a higher-level logical abstraction that defines access points at the beginning of each "chapter" (of "section" or any other relevant structural position), so here for example at the zero timestamp chapter1-a.mp3#t=0. The second physical part chapter1-b.mp3 does not need to be linked from the TOC, as during playback it will automatically be scheduled after chapter one, just as per the reading order definition.
Of course, the TOC can also link to the beginning of other (sub)parts inside individual "chapters", such as "sections" etc. For example:

• chapter1-a.mp3#t=0 (beginning of chapter one)
• chapter1-a.mp3#t=111 (beginning of section one inside chapter one)
• chapter1-a.mp3#t=222 (beginning of section two inside chapter one)
• chapter1-b.mp3#t=0 (beginning of section three inside chapter one)
• chapter1-b.mp3#t=444 (beginning of section four inside chapter one)
• chapter2.mp3#t=0 (beginning of chapter two)
• chapter2.mp3#t=111 (beginning of section one inside chapter two)
• chapter2.mp3#t=222 (beginning of section two inside chapter two)

Or am I missing something?
Thank you

[LFriedenthal]

Daniel, It did not occur to me that 03_chapter1b.mp3 should be lumped in with the duration of 02_chapter1a.mp3 by virtue of NOT being referenced. There are no examples of how to handle this case on the spec page, so I figured I would ask, so I can clarify expectations for our devs. I thought there would be two entries for the same chapter because that's what JayPanoz's audiopkgr software does by default when it makes a TOC. (RecordedBooks puts the same ID3 tag information for the a and b mp3s of the same chapter, so when the packager looks at the files, it uses those for the names and creates duplicate names.) I'm not sure what Coresource would deliver in a book where this was the case. My journey toward trying to figure out what we're meant to use looked something like this: We need to know what to actually write on the display. Since the manifest doesn't support media fragments, a file with multiple stories inside it gets one manifest entry and you have to name all the stories as one "chapter name". "for content where multiple chapters occupy a single file by using media

fragments [media-frags] to locate the exact starting and end points." BUT "It is important to note that a resource cannot be referenced more than once in the reading order. In the case where an audio file represents the content of multiple chapters or sections of the book, the table of contents can be used to specify the starting and ending points of those chapters in the larger audio file, as demonstrated in this example."

I don't know why you say both those things. But it seemed to be the case that the manifest was not the best place to find the TOC, then. I was looking in a Macmillan title from Coresource as a reference. The TOC as communicated with Kobo's manifest.json made it pretty clear the order files were to be played in and what the TOC should say, which each short story getting identified within a single mp3. The manifest.json in the LPF was a worse source of information, but I saw the note above and looked at the toc.html. The TOC.html identified each story and had a navigation point with its own name. So then it seemed like the TOC is the thing you want to use because the information is more granular. But the TOC didn't let you say a single chapter occurred over multiple files, which is way more common. So, that brought me here. [image: photo] Lora Friedenthal Pronoun(s): She/Her/Hers Senior Content Operations Specialist at Scribd <http://www.facebook.com/scribd> <http://www.linkedin.com/company-beta/129665/> <http://twitter.com/scribd>

…

On Thu, Mar 30, 2023 at 11:55 PM Daniel Weck ***@***.***> wrote: Hello, I don't understand why the TOC contains two links to chapter one, in your example. The publication's reading order may indeed reference as many physical audio resources as needed (e.g. chapter1-a.mp3 followed by chapter1-b.mp3), but the TOC is meant to be a higher-level logical abstraction that defines access points at the beginning of each "chapter" (of "section" or any other relevant logical position), so here for example at the zero timestamp chapter1-a.mp3#t=0. The second physical part chapter1-b.mp3 does not need to be linked from the TOC, as during playback it will automatically be scheduled after chapter one, just as per the reading order definition. Of course, the TOC can also link to the beginning of other (sub)parts inside individual "chapters", such as "sections" etc. For example: - chapter1-a.mp3#t=0 (beginning of chapter one) - chapter1-a.mp3#t=111 (beginning of section one inside chapter one) - chapter1-a.mp3#t=222 (beginning of section two inside chapter one) - chapter1-b.mp3#t=0 (beginning of section three inside chapter one) - chapter1-b.mp3#t=444 (beginning of section four inside chapter one) - chapter2.mp3#t=0 (beginning of chapter two) - chapter2.mp3#t=111 (beginning of section one inside chapter two) - chapter2.mp3#t=222 (beginning of section two inside chapter two) Or am I missing something? Thank you — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUH7HM7Y7I3VWAZY4F2FEY3W6ZITBANCNFSM6AAAAAAWNKK5CA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mattgarrish]

The TOC as communicated with Kobo's manifest.json made it pretty clear the order files were to be played in and what the TOC should say, which each short story getting identified within a single mp3.

The table of contents doesn't define the order the resources are supposed to be played in. That's defined in the manifest in the readingOrder property. What @danielweck is saying is that your reading order will list each part of chapter one:

"readingOrder": [
   { "url": "chapter1-a.mp3" ... },
   { "url": "chapter1-b.mp3" ... },
   { "url": "chapter2.mp3" ... },
   ...
]

That is what the reading system uses to determine the flow of the audiobook.

The table of contents only provides links for users to access specific points, so you can forget about the fact that chapter 1 is technically split into two physical audio files and link to the one that actually represents the start of the chapter, chapter1-a.mp3 in this case.

A program that automatically generates a table of contents based on file names will probably create duplicate entries, but then all you have to do is prune those excess entries from the TOC if they're not relevant. So long as the reading order is complete, it has no effect on playback.