Excessively long save operation when writing chapter metadata in audiobook files

Support
1

When editing metadata on my audiobooks, I often find myself needing to write different author and narrator (composer) metadata to each chapter. For example, when the book is a collection or anthology. I want to have the specific author/narrator of a poem or short story rather than a list of authors or narrators so long that the specific author doesn't even show up on my device's display. It's not crucial, but it satisfies my nit-picky perfectionist side.

Any way, I've noticed when I edit the metadata and then save, it takes a LONG time. The longer the book, the more chapters/tracks in it, the longer it takes.

Obviously these files are very LONG audio files with many tracks, much longer (and often with many more tracks) than most music albums, which is probably why this issue might not be apparent to people who use it for music files.

So, say I have a 30 hour short story anthology containing a total of 160 chapters from all the stories combined, if I wanted each story to have the correct author and narrator, it might take over 90 minutes to save a 1.3GB file on a heavy-duty gaming computer.

Admittedly, the file is stored on an external 1TB SSD drive, so maybe it's the USB connection; I've only just now considered attempting it from one of the internal drives.

ETA: Running a test now but for the moment, no discernible difference. A single chapter out of 163 took over 36 seconds, which means the whole book will take around an hour and a half.

If I had to guess, I'd say it seems like the save process is saving the file all over again after changing the metadata for each individual chapter. Like, it edits one chapter's metadata, re-saves the file, edits the next chapter's metadata, re-saves the whole file, etc etc. But I have no idea if this is the case. It's just the first possibility I can think of.

2

To exclude the external 1 TB SSD you could copy the file(s) on your internal local drive.
(Is this a SSD too? Or a HDD?)

How does it change the writing time?

And what kind of files do you use? FLAC? Mp3? Something else?

3

The files are chaptered .m4b audiobook files, and thus far moving to my local HDD hasn't made a significant difference. I started the operation when I made the initial post a half-hour ago, and I'm only 1/3 of the way through.

4

You could make a simple test and time it:
Copy the file from your external usb storage to an internal drive and back again.
How long does that take?
Just a comparison: USB has a conection speed of 20 to 60 MBps, the SATA bus has up to 6GBps.

5

It can also be the SSD itself. Many somewhat cheap SSDs (and these in turn are often built into external SSDs) write slowly with large amounts of data. This is partly due to the NAND cells used (e.g. QLC).

They are fast until their cache is full and then slow down to a fraction of the full write rate. Furthermore, they heat up when writing and throttle to avoid overheating.

Normally this behavior is not a problem, as the normal case is reading data (at boot time) or writing small files. The fast access times of an SSD are very useful here. But if you have a local scenario that repeatedly involves writing large amounts of data in one go, you should choose an SSD-model accordingly.

6

This is very likely happening, as you are adding far more data to the header than may have originally been available. The same happens with movies this first time you add or modify them as well. To confirm this, once you have made changes to one of your audio books that took some long time to save - make another small change to the same file and save it again - note if the 2nd save is done significantly faster.

7

Thanks, I will test this. It's actually still processing from when I started my test upon making this post, because it wasn't done when my computer went to sleep after I went to bed. I will initiate a new test.

However, made multiple successive edits with other files, I didn't notice a significant decrease in the time it took on the later edits. I will try again, but I'm not confident that this will solve the issue.

Before I start another test that may take a long time, though, I want to make sure I'm giving all the information here, as there are a couple things I forgot to mention.

  1. I'm in "List Chapters as Separate Files" mode, obviously, since I'm making the edits on a per-chapter basis. So it IS handling each chapter/track as though it's a separate file, which I assume means doing exactly what I speculated it was doing. If there is a way to save all edits to affected chapters without having all the chapters selected and treated as though they are individual files, I don't know what it is.

  2. Even when not dealing with chapters that may have different artist/composer data than others in certain kinds of audiobooks, the reason I'm doing my final save in "List Chapters as Separate Files" mode is because I'm also generating an .nfo file that lists each chapter and its duration, like this:

********************
*                  *
*     CHAPTERS     *
*                  *
********************
01. Opening Credits                                             00:33
02. PART I: MANTICORE                                           00:03
03. Chapter 1                                                   31:09
04. Chapter 2                                                   26:14
  1. When writing the same data to multiple tracks, it happens almost instantly if I do it track-by-track in the spread-sheet layout than if I do it by selecting multiple tracks and making the edit in the tag panel and then save. But when dealing with an audiobook with (potentially) dozens or even hundreds of chapters, this isn't efficient and ends up taking as much time anyway.

If the technical reasoning for this happening is what we believe it to be, wouldn't it make sense to calculate the amount of header space required for ALL queued edits to chapters/tracks in the same file and then conducting the save as a single operation?

8

Thank you, this is helpful information even though I can now conclude that the problem I'm having happens regardless of whether I'm writing to an external SSD or an internal drive. I was unaware of this and will remember it for future purchases.

9

Thanks. Copying the file back and forth takes only a few seconds, and conducting the save operation on my internal HDD takes every bit as long as it did when I was doing it on the external SSD, so that is ruled out as the source of the problem.

10

Are we talking of 1 big file or many smaller files? Tracks from a music album are generally stored in files per track.

11

In this case, it's one big file. An .m4b is a chaptered .m4a file, so when you list chapters as separate files, basically what it's doing is showing each chapter individually, but they're all still part of the same, large file.

So whatever changes are made to a single chapter or a set of multiple chapters, what appears to be happening is that the file will be edited and saved for each individual chapter being edited. Since audiobooks can be quite large and have many chapters, this can obviously become quite time-consuming.

12

Here is a thread that reports a similar behaviour.
But apparently that never got to an end:

It would be nice if such a file could be supplied for testing purposes.
Also, there has been a report about MP3tag loading files and the defender.

Perhaps this contributes to the problem