Feature: Support multi-file audiobooks

[bryanrezende]

• Support playing audiobooks broken into multiple sequential files
• Need to determine how to tell if files are part of a whole.
  • Filename-2 characters?
  • Title in metadata?
• Need to determine how to save files to storage/book entity to database

[GianniCarlo]

one possible way to mitigate the need to play an audiobook that is broken in multiple files, is to create a playlist https://github.com/GianniCarlo/Audiobook-Player/issues/14 . I've considered providing the user with a way to merge the files, but I concluded that it was out of scope because that feature could easily be another app.

That said, let's say you find a way to determine that two files belong to the same audiobook, how would you handle the order of reproduction of the files? would it be necessary that they always have a suffix with their part number? or is there a more reliable way of doing it?

[bryanrezende]

I was thinking about resolving this with a playlist feature, but the problem I see with it is that a playlist would require the user to (most likely) manually create it, and would make it so that each file would need to be displayed as a separate list entry in the home list. Ideally a user could download an entire directory of separate files from dropbox or another service and have it show up in the home list as a single book entity.

I started to take a look at the metadata we could expect well-formatted books to contain to see if there's something we could use. Here's the output for a book I downloaded from Downpour (Paid but DRM-free service) :

We have the ItemAlbum and the ItemTrackNumber that we could use to tell if they belong to the same book and determine their order, and this metadata is (I believe) also included in mp3s.

We could read this data to compile book entities and play files sequentially - the background logic for which would also basically be what we'd need for playlists too, right?

Edit: I also want to look into what's included in the 'extraAttributes' of AVMetadataItem within iOS. That might just give us everything we need! I'm planning on taking a look at it later tonight after work.

[bryanrezende]

@GianniCarlo I pushed up some minor realm fiddling to my feature_realm_spike branch while trying to learn realm and was wondering if I could get your input on it since you've worked with it before!

My main question: Is it good practice to have both a class to manage realm content and a class to manage the local data, or should I look into consolidating them? I want to make it as future-proof and adaptable as possible.

My not-so-main question: Do you see anything wrong with my implementation of adding books to realm (other than it re-doing a call to the datamanager + my not filtering local files to audio yet) before I get too far into it?

[GianniCarlo]

I'll look into it today after work and comment 👌 I was planning on checking this out yesterday but that compiler optimization bug took more time to figure out than I expected

[GianniCarlo]

I don't think we should have two book entities, unless we can justify the extra overhead of having two types of instances for the same, it's cleaner if we just stay with the realm entity. Also we could use the DataManager to handle all the loading operations.

I didn't want to comment on the commit because I'm aware it's a first draft, it'd be great if you could split one commit just for the added Realm framework though, I was looking through it and I thought you were including travis too, but it turned out it was from the Realm dependency 😅.

[bryanrezende]

I was definitely planning on removing the non-realm book object, I just wanted to get Realm working first since I had never dealt with it before - or even Carthage, for that matter! I'll split the branch and get just the Realm framework in, and pull the BookEntity stuff over into another branch.

I also realized there's a whole bunch more I want to add to the book entity (and stuff we probably need to add to properly support multi-file books like which file you last paused in, your position in that file as well as your position overall, since some users might want to delete individual files as they complete them to save space on device). That BookEntity could get big!

[ghost]

Is there any progress on this issue? This feature is an important one to me; I'd be happy to help out with the implementation.

(Also, is this fork still active, or should this issue now be discussed in the upstream repo?)

[bryanrezende]

@ljfft Whoops, this fork should probably be shuttered. I was working on this last about a month ago but things got very busy personally and that slowed development to a full stop. I believe I have a branch pushed up to the main repo with my last progress, but things have been slowing down and I think I can jump back onto development soon. Either way, I'll get the current progress pushed up somewhere so that someone can continue it if I can't.