View Single Post
Posts: 2 | Thanked: 2 times | Joined on Jun 2010
#245
Originally Posted by thp View Post
A workaround for 0.3.x that you might or might not like is to merge all that small files from the CDs into one big file. Look for "MP3 joiner", "MP3 merge tool", etc.. on Google.
Originally Posted by thp View Post

Even on a Desktop computer I find it much more pleasant to have a slider for the whole show/audiobook/mix than to have to navigate through a playlist of many small files.

Splitting audiobooks in many small files is really just a relic of the way CDs worked back in the day (i.e. no direct "seeking" with a UI and a slider, but rather a very easy way to switch between tracks). Where in 1994 you had to remember "disc 4, track 7", today Panucci remembers "107 minutes and 39 seconds" for you

Originally Posted by thp View Post
And no, not even the "chapters" of books are a reason to split audiobooks into multiple files. There are ID3v2 chapters for MP3 files: http://www.id3.org/id3v2-chapters-1.0 and I know that there is a way to have chapter marks for MP3 files. Haven't seen anything for .ogg yet. Chapters in files just lack the support in players and encoders most of the time, but the format is specified and some sources already use it.

Due to the fact that Panucci resumes files at the position that you stopped them, there are no problems with extremely long files (and I myself make use of that feature when listening to two-hour-long DJ mixes or podcasts which are also often longer than one hour).
I have been wondering if pannuci is the solution to my audiobook maemo needs and it's comforting to hear you saying this, as this is what I have always done. When dealing with audiobooks for a long time you come to loathe having multiple files, if nothing else because they are messy in your directory structure. Also you want to be able to navigate across the whole audio, and preferably not deal with playlists. But I wanted to ask if these features and processes you are describing are actually supported in Pannuci...

Specifically, the problem is that books can get up to 70+ hours. Still, in an age where we throw around 700meg files for low res movies, very large audio files are a viable option, and indeed the best one IMHO for dealing with long audio books. In order for it to be worth the trouble to convert them this way, you HAVE to have the chapter data from the filenames and ID3 tags of the original files preserved within the long files. This way it is like zipping all the files up into one long file that can be played directly and not lose any valuable track information.

As far as I knew, m4b was the only format that could preserve chapter data so I spent almost a month last year in foobar2000 sorting and converting 150 gig of audiobooks (in random small files) into 30 gig of single huge 20kbps m4b files for each title. The most extreme case was an entire podcast series' with almost 200 podcasts. So 2 hours is not a long file, even 15 hours isn't really that long compared to (the most logical way to store) say Atlas Shrugged, the Bible, a TTC lecture series, or an stored podcast series. I've gotten the impression Panucci was really designed more with short (hourish) podcasts in mind

Here are my issues and concerns:
1. Since panucci is an audiobook player, why does it open m4a but not m4b audio files? It is the same encoding as m4a I think and infact some m4bs (that arent too long) can be renamed to m4a and they open and play in panucci. Seems like as easy as changing a function call in a case block for m4b files, to just play them like m4a.

2. You mention that chapters are no excuse to keep small files apart, but does Panucci support chapters? My renamed m4b files do not preserve their chapter data when opened in pannuci. Even forgetting m4bs, I would prefer to put them in this ID3v2 mp3 format, but still I see nothing in the interface to support chapter skipping, only short and long time skipping.

3. What is the deal with panucci and huge files? Given that huge in the scope of an audiobook player means 70+ hours. I have had issues with my device consistently crashing before it can begin playing files bigger than about 5 hours. Granted these are m4bs renamed to m4a, so this might be part of the issue.
I really think a serious audiobook solution should be able to handle audio files nearly up to a gig, or upwards of 100 hours. Could it, rather than loading the whole file into memory, just load blocks for the next (lets say) 5 minutes, and thus make the total file size irrelevant? Maybe that is already what it does...
 

The Following 2 Users Say Thank You to jamesbarrett For This Useful Post: