I've understood that the iTunes encoder is does not produce gapless AAC files; it adds samples of silence at the end of the file (and beginning?). Other encoders as Nero and FAAC do produce gapless files. Is it possible to alter iTunes-made files in order to make them gapless, for use in an iPod with Rockbox?
Gapless playback always needs player support too, so it would depend on Rockbox as well.
QUOTE(Garf @ Apr 9 2006, 11:25 PM)

Gapless playback always needs player support too, so it would depend on Rockbox as well.
Ipod rockbox is gapless for all its gapless supporting formats. So, as far as I know FLAC, Wavpack, Lame mp3 and vorbis are gapless-able on rockbox.
I'm not sure what you mean here. Are you saying it already has support for gapless AAC playback? As far as I know that's not even properly possible for iTunes encoded AAC. So what *are* you saying?
From the Rockbox FAQ:
Will Rockbox support gapless playback?
Yes. Rockbox has been designed from the start to play back music without inserting any extra gaps between tracks.
I thought that if the silence at the end of the track was removed from the file, it would be able to play gapless. Maybe it's not that simple? I don't know how it handles FAAC and Nero files, though.
You need to know
- How large the encoder delay is (*added* silence in front)
- How large the input file is (*added* silence in the back)
Just removing silence obviously doesn't work. A file with a silent intro would not be cut to the correct length.
I didn't quite write what I meant there. I thought not about general silence at the end of the track, but of the silence added by the encoder. But it leads me to another thought:
If I know what files are supposed to have no silence at the end or the beginning of the track, files part of a live concert for example, is it possible to remove that silence (of course it would be in a sound editor, but perhaps automated by a program)?
QUOTE(Morx @ Apr 10 2006, 02:11 PM)

I didn't quite write what I meant there. I thought not about general silence at the end of the track, but of the silence added by the encoder.
..which needs the encoder to communicate exactly that. As far as I know, iTunes doesn't communicate it, and I have no idea if Rockbox can correctly deal with files where it IS communicated.
Maurits
Apr 10 2006, 08:48
QUOTE(Morx @ Apr 9 2006, 11:08 PM)

I've understood that the iTunes encoder is does not produce gapless AAC files; it adds samples of silence at the end of the file (and beginning?). Other encoders as Nero and FAAC do produce gapless files. Is it possible to alter iTunes-made files in order to make them gapless, for use in an iPod with Rockbox?
AFAIK all lossy formats add silence to the files. The trick to playing gapless is having an extra field inside the files header to tell the decoder what silent parts to skip on playback.
A gapless capable player will read this and skip the silence only if the file contains info on what to skip, if an iTunes encoded AAC file lacks that info (and it does with the present version of the encoder) a player can not skip the silence.
Ok. Perhaps it's best to give up any hopes of using iTunes-mide AAC for gapless playback then?
davechapman
Apr 11 2006, 08:06
When Rockbox describes itself at gapless, it means that it doesn't insert any extra gaps between two tracks. So where either the format itself doesn't add extra samples to the beginning and end (such as any of the lossless formats), or the decoder library takes care of trimming those samples (which I'm guessing is the case for Tremor/Vorbis), then playback will be gapless.
Rockbox does a pretty good (but not quite perfect if my understanding is right) job of trimming silence from the output of libmad to make Lame-encoded MP3 files gapless, but there has been no similar work for AAC - Rockbox will play whatever samples libfaad outputs.
Patches to solve this are welcome, but because the AAC decoder used in Rockbox is not realtime on the iriver/iaudio players, and is only just about realtime (for 128kbps files) on the ipods, there hasn't been much work on the higher-level parts of AAC decoding so far.
Ivan Dimkovic
Apr 11 2006, 08:24
Making AAC gapless is not a big deal, providing that you are the codec author

Guessing third-party codec's internals (encoder delay, extra added samples, etc...) is quite hard, and - yes, finding out how much of the samples at the last frame should be cut is not possible without knowing the lenght a priori, as Garf point out.
In addition, codecs could have a variable delay, and that could vary from version to version - from coding mode to coding mode.
Mike Giacomelli
Apr 11 2006, 13:44
QUOTE(davechapman @ Apr 11 2006, 07:06 AM)

When Rockbox describes itself at gapless, it means that it doesn't insert any extra gaps between two tracks. So where either the format itself doesn't add extra samples to the beginning and end (such as any of the lossless formats), or the decoder library takes care of trimming those samples (which I'm guessing is the case for Tremor/Vorbis), then playback will be gapless.
Rockbox does a pretty good (but not quite perfect if my understanding is right) job of trimming silence from the output of libmad to make Lame-encoded MP3 files gapless, but there has been no similar work for AAC - Rockbox will play whatever samples libfaad outputs.
Patches to solve this are welcome, but because the AAC decoder used in Rockbox is not realtime on the iriver/iaudio players, and is only just about realtime (for 128kbps files) on the ipods, there hasn't been much work on the higher-level parts of AAC decoding so far.
Dave, I've been wondering about FAAD. Its my understanding that it has SBR support, but that this was not possible to support in Rockbox. Is this because the SBR decoder is not integer based? Or was it simply too slow to work on the ARM7 cores in its current state? I've been looking at the Helix decoder, but unless Rockbox grants an exception to the GPL (yeah right), I guess it can't be used, which is annoying since it appears to be faster then any lossy decoder already running on ARM-Rockbox.
One of the ideas that I posted above was about removing silence (manually for each file) that you know isn't supposed to be there. If you know that one file shouldn't begin with silence or end with silence, is it possible to delete it? Would this work with the decoder or does it "expect" the silence to be there?
Mike Giacomelli
Apr 11 2006, 23:31
QUOTE(Morx @ Apr 11 2006, 01:22 PM)

One of the ideas that I posted above was about removing silence (manually for each file) that you know isn't supposed to be there. If you know that one file shouldn't begin with silence or end with silence, is it possible to delete it? Would this work with the decoder or does it "expect" the silence to be there?
Thats how most gapkiller plugins for nongapless systems work. They're not bad, but not great either.
QUOTE(Mike Giacomelli @ Apr 11 2006, 09:44 PM)

Is this because the SBR decoder is not integer based? Or was it simply too slow to work on the ARM7 cores in its current state? I've been looking at the Helix decoder, but unless Rockbox grants an exception to the GPL (yeah right), I guess it can't be used, which is annoying since it appears to be faster then any lossy decoder already running on ARM-Rockbox.
FAAD2 works in integer based modes for SBR and PS too. As far as I know, the Real decoder isn't actually faster on real devices. But yes, decoding SBR on an ARM7 is going to be tricky, no matter which one you use.
WarChild
Apr 17 2006, 12:14
My listening habits don't require gapless playback.
that understood I've always been intrigued by the need for it, I mean, if I want it gapless I would just encode the whole thing as 1 track.
I really can't understand the need for this, other than understanding that it is sometimes irksome to have a life recording abruptly stop and restart. I'd guess it's a similar thing for the codec designers.
Mike Giacomelli
Apr 17 2006, 12:35
QUOTE(WarChild @ Apr 17 2006, 11:14 AM)

that understood I've always been intrigued by the need for it, I mean, if I want it gapless I would just encode the whole thing as 1 track.
Thats a pretty annoying way to do things though since it prevents you from skipping tracks. It also tends to cause problem for audio players since they can't buffer as effciently and since seeking though many formats is slow and power hungry.
QUOTE
I really can't understand the need for this, other than understanding that it is sometimes irksome to have a life recording abruptly stop and restart. I'd guess it's a similar thing for the codec designers.
I think thats pretty much the gist of it. I don't really care about gapless, but then I'm not too picky about my audio. I think a lot of people are just sensitive.
Slowcoma
Apr 19 2006, 23:01
I listen to a lot of opera. If I want it gapless I have to encode the entire CD into one track. Have fun finding anything with that. Maybe I'm overly sensitve but I don't think it's asking too much to have my codec give me the functionality of a 1983 CD. I mean you guys make thousands of posts debating things you probably can't really hear anyways. Tell you what - I'll ABX gapless vs. non-gapless any time you want. I'm pretty sure I'll be able to hear the difference.
ilikedirtthe2nd
Apr 20 2006, 05:53
QUOTE(Slowcoma @ Apr 20 2006, 05:01 AM)

I listen to a lot of opera. If I want it gapless I have to encode the entire CD into one track. Have fun finding anything with that. Maybe I'm overly sensitve but I don't think it's asking too much to have my codec give me the functionality of a 1983 CD. I mean you guys make thousands of posts debating things you probably can't really hear anyways. Tell you what - I'll ABX gapless vs. non-gapless any time you want. I'm pretty sure I'll be able to hear the difference.
You're not alone

just what I am thinking for so long...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.