Hacker News Reader

Comment by apitman | Hacker News Reader

In case you didn't know, you can use FFmpeg to convert Audible aax files to DRM-free MP3/AAC/whatever [0] (scroll down for FFmpeg instructions).

This is useful if for some reason you want to archive them or play them in an app that doesn't constantly change its UI and bombard you with ads.

[0]: https://www.kylepiira.com/2019/05/12/how-to-break-audible-dr...

View on HN

If you're converting .aax files you should consider using .m4b as the output, since it preserves chapters and remembers your last listened timestamp [0]:

> Audiobook and podcast files, which also contain metadata including chapter markers, images, and hyperlinks, can use the extension .m4a, but more commonly use the .m4b extension. An .m4a audio file cannot "bookmark" (remember the last listening spot), whereas .m4b extension files can.

The cool thing is that once you rip your activation bytes, it works for all your audiobooks. Would definitely recommend it.

[0] https://en.wikipedia.org/wiki/MPEG-4_Part_14

I don't think that's quite accurate.

There's no functional difference between a .m4b file and a .m4a file. Both use the MP4 container so adhere to the same specification, so support all the same features (including bookmarks). FFmpeg even uses the same muxer and demuxer for both "formats".

The only difference is a non-standard convention used by certain software (like iTunes) to write autiobook-related metadata only to MP4 files that use the .m4b file extension.

You'll get exactly the same result if you just change the file extension after remuxing/transcoding.

Well, it's also worth noting that different file extensions can have different associations, so .m4b is more likely to open in an app that the user wants to use for audiobooks, rather than opening in a generic mp4 audio playing app.

Even iTunes, I think, would treat files differently between m4r (Ringtone) and m4a (audio) files, so despite there being no difference at all, using the 'correct' extension might be quite a bit more convenient in the long run.

This is true and I'm not saying you shouldn't use the .m4b extension, I just want to make it clear that that's the only difference.

A ".m4b file" is just an MP4 with a funny file extension.

>Even iTunes, I think, would treat files differently[...]

Yes, because it's Apple (of course) who started using non-standard .m4a, .m4b and .m4r extensions, instead of the standard .mp4.

I don’t see a problem with .m4a and .m4v for standalone streams of AAC and AVC respectively.

Wait, so an m4b stores playback position in the file itself? As in, the checksum will change and file syncers like Syncthing will re-upload every time I hit pause?

audiobook-related metadata does not include the current play position, in this case. It includes things like author and editor and narrator.

No, that's entirely player-specific and has nothing to do with the MP4 format at all.

I don't know Syncthing internals, but state of the art in file syncing is to use rolling checksums to identify which parts of the file have changed. If only a few bytes of the file are overwritten, only the immediate vicinity of these bytes would be synced.

So it writes the timestamp to the file metadata? That would cause issues with syncing, backups, running from a read-only filesystem, etc. My audiobook app already keeps track of current timestamp for me.

And where does the audiobook app store the current timestamp?

Probably in the app data directory, which I prefer.

it sounds like .m4b is just a flag that tells the player "treat this as a book, not a music file"

Isn't bookmarking a job for the player? Then it shouldn't matter what file type you use.

The information online about M4A vs M4B is wrong. There is no difference other than the file extension. The Wikipedia article links to a lifewire.com article about the bookmark claim. This container format can store XMP metadata, and you can certainly have a player that saves a playback position in the file's XMP metadata, regardless of its M4A or M4B extension. But every player I know of doesn't do that. They store playback positions in their own internal database.

This claim seems to originate from the fact that the old iPods only remembered the last played position on M4B files. But that's entirely a player convention, not a file format convention.

Note that Audible now uses the significantly harder to break AAXC file format in its mobile apps.

AFAIK FFmpeg does not yet support this decoding. There is a patch available: https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/202004...

That's disappointing. Do you know if there's a cracking tool out yet?

I just tried and it looks like you can still download aax through the browser.

The amount of time I spent on correcting wrong chapter marks (like the first four books of the Wheel of Time) is masochistic. But I am absolutely happy that I have the possibility of doing so after the conversion :)

Heh, I just started The Dragon Reborn on my 3rd read-through. I have noticed the chapters aren't right, but it hasn't really bothered me. What does your workflow look like when fixing these? Is there a way to share chapter corrections so others can apply them to their files?

I have the corresponding ebooks too, so I open up the whole audiobook as one file and guess where the chapters are from the waveform. I listen to the guess and compare to the ebook, checking whether I am too far or too early. Once I find the correct position (and I got quite good at spotting it from the waveform), I set a marker and start with the next chapter. In the end I split it along the markers.

I was planning on writing something to spot when they say "chapter" as it is always the same but I never got around to that. Also, doing all that work was almost meditative :)

A way to share the corrections would be to export the markers from audacity but sadly I don't have that data anymore, though I could calculate the markers from the files I exported if you are interested.

Yeah that does sound like a lot of work. I appreciate the offer but like I said it hasn't bothered me much. I don't know that I've ever relied on chaptering for audiobooks, other than for breaking the book into smaller pieces to make the scrubbing less sensitive. My mental model is much more of a linear monolith.

Well, if you own the epub, you could try to find out the whole length of the audiobook, then extract the whole text of the epub splitted by chapters and then relatively match the text length to the audio length and put the chapters where the nearest silence is (chapter 2 is at 3.3845% of the whole text, so seek for a silence around 3.3845% of the audio length)

I got some pretty good matches with m4b-tool here, while it does not work for all audio books (you need the latest pre-release for this very experimental undocumented feature!):

  # try to match my-book.epub on my-audiobook.m4b
  # ignore first, second and last two epub-chapters for the match (dedication etc.)
  # split chapters into sub chapters to ensure they are between 5 and 15 minutes
  # create a backup of the original chapters (done automatically)
  m4b-tool chapters -v --epub=my-book.epub --epub-ignore-chapters=0,1,-1,-2 --max-chapter-length=300,900 "my-audiobook.m4b"

  # omg it did not work and messed up all chapters, please restore the original chapters
  m4b-tool chapters -v --epub-restore "my-audiobook.m4b"

  # ok, lets only dump the findings in chapter.txt format to do it manually
  m4b-tool chapters -v --epub-dump --epub=my-book.epub my-audiobook.m4b

Maybe you would like to try m4b-tool chapter-adjustment by musicbrainz id or silence-detection? :-) Disclaimer: I'm the author - https://github.com/sandreas/m4b-tool

I once planned a chapter database (https://www.chapter-db.org) to collect work like yours, provide an online chapter editor and bind an api to m4b-tool, but i did not have the time to finish the project.

Oh, very interesting, thanks for the hint :D

Reply on news.ycombinator.com