When ripping audio books to my iPod, I often join the files (at import) and then have iTunes “remember playback position” which converts the file from .mp3 to .m4b. Other times I do this with the Mac program File Joiner.
Anyway, being able to remember playback position is key when one’s tracks are as long as a CD, of course, but I’ve noticed that the iPod crashes sometimes when using these files (and yet never crashes when using Audible.com’s proprietary format .aa, which also remembers playback position).
Does anyone have an idea why this is happening? I was using an iPod Video, 30Gb, 4th gen. I have an iPod touch now, but haven’t tried a .m4b file on it yet.
And what does this have to do with Audacity?
I kinda figured “all things audio” and “audio processing” were broad enough containers. No?
True, but your question is specific to iPod. There may be someone here who can help, but you will probably have a better chance of getting an answer on the Apple forums.
Point taken: I’ll post there, too, but I should mention that the same thing happens in iTunes. Again, Apple, but I have a feeling it would occur on any player. Meaning that the issue seems to be in the conversion to .m4b, not in the player, methinks. On the Audacity tutorials about exporting to iTunes (and thereafter, the iPod) it mentions that 24-bit sound has issues on the latter, but that can’t be the case here b/c it’s a CD rip, and so 16-bit.
Ideally, I’d be exporting from Audacity with the intention of creating tracks that remember playback position on whatever plays them, but I wouldn’t want the listener to suffer the whole crashing or skipping thing, which is where all this comes from.
You could consider breaking up your long tracks into smaller tracks and threading them together on iTunes via an “albem title” or a playlist.
Personally I use AAC (Apples’s own lossless format) in my iTunes library. I export WAV files from Audacity and use iTunes to convert to AAC (iTunes does this conversion about twice as fast as Audacity).
I also have several radio plays from the BBC on one of my iPods, these are single AAC files of around 1-1.5 hours. They all play perfectly and the iPod happily remembers the playback position if I turn off the iPod and later restart it.
@wax - Thanks for the info; I’ll give that a try. I admit an overall ignorance of how best to manage iTunes in general, and I haven’t monkeyed with lossless too much, though I envision offering a lossless option for what I produce. Didn’t know AAC remembers position, which is a necessity for me.
you’re welcome. Have a look at this workflow tutorial I put together for the 1.3/2.0 manual: http://manual.audacityteam.org/man/Sample_workflow_for_exporting_to_iTunes
This one tells you how to break up the recording into chunks (like the tracks on a CD): http://manual.audacityteam.org/man/Splitting_a_recording_into_separate_tracks.
<<Didn’t know AAC remembers position …>>
It’s not the AAC that does that, it’s iTunes that does the remembering of current playback position.
For which the best advice I can give you is to make sure that you set your iTunes so that it actually copies the audio files into your library AND make sure backup your iTunes library from time to time to at least one external disc (preferably 2 or more). External USB discs are fairly cheap these days - losing an iTunes library can cost you a lot of work.
I didn’t know about the “m4b” file format, so I searched for more info about it. It appears to be a modified mpeg-4 container similar to m4a files but with the ability to save chapters and bookmarks in its metadata fields. The audio contained in m4b files is probably encoded in AAC.
Now translating this to common english… There are two different concepts regarding audio and video files which most people aren’t aware of: container and encoding format.
I’ll start by the second… Encoding format is the way that the audio/video data is stored on the file, most of the formats have the aim to compress the data. Some codecs do that by sacrificing quality (the so called lossy codecs, such as MP3), while others can achieve some compression without quality loss (they call this ones lossless codecs, example: FLAC).
The container is just that… a container. The container usually has 2 parts: metadata and data. The metadata is a series of informations about the data in the file or the way it is stored on the file, etc.
A good example of this is ogg vorbis. Ogg is just the container, while Vorbis is the codec (software implementation used to encode/decode data).
Another example of a popular container is matroska (.mkv files). Matroska files can contain a lot of different formats in it, from video to audio, or subtitles. But all the data contained in a matroska file must be encoded using some other encoding format. For example the video can be mpeg4 while the audio can be mp3 and the subtitles can be srt format.
Then the matroska metadata contains a lot of information about the data stored in it, such as the encoding format, and where in the file each piece of data is stored.
Back to the m4b files… Apparently this container is able to store bookmarks in its metadata. That means that a player (that understands that container) can “save” information to the file about the current playing position (ie the player can actually alter and write on the file).
Therefore from what I can understand an .m4b file that is played in one player (eg iTunes) and stopped somewhere in the middle, can then be opened in another player (eg the iPod) and it will resume the playing position.
Other file formats such as mp3’s lack this ability, so this feature won’t work while transferring files from one player or computer to another one.
Some players though have the ability to resume file playback even if the file format does not store bookmarks. That means the player stores that information somewhere else other than the audio file. I have a portable audio player from sandisk (sansa clip+), which has this feature for podcasts. Regardless of the file format it saves the playing position and it resumes when I play that file again later.
Sorry for the long description but I couldn’t make it clear enough in shorter