Could we add gapless to Apple's AAC encoder?, task for iTunesencode or other? Options

[guruboolez]

I have a question about a possible new iTunesEncode feature (or any other program driving Apple's AAC encoder). Wouldn't it be possible to add a gapless feature? It might sound silly, but after all, nyaochi did it with the latest Fraunhofer MP3 encoder (here and here). I'm not a coding expert -I'm not a coder at all- but I think that doing it wouldn't be an impossible task.

Adding somewhere in the tags the precise offset (constant for Apple's encoder) and calculating the amount of padded sample maybe suffice? I don't really know. faac and Nero AAC are gapless, and apparently Apple is not hurry to implement this feature. It's a pity, because Apple's encoder is pretty good. Gapless playback is not possible on any iPod, but on a computer (playing with foobar2000 as exemple) users would benefits from it.

Could we reproduce Nyaochi's ACMenc patch to work with iTunes? Or make something similar? What do you think?

[Tropican]

Sorry, my last post was poorly written.

You missed the point. AAC stream seems to have 1024 frame size, which means that you will/must get 1024*n samples after decoding an AAC stream. That's one reason why iTunes must pad silent samples to fill the last frame. And there's another reason from encoder delay, but I don't mention here. Anyway, the necessary task is not removing the silence, but telling a decoder the number of samples to be removed for playback. It cannot be achieved by an audio editor.

I actually didn't miss the point, but used an incredibly bad example. I was just wondering if we could implement already existing silence cutoff code. A better example would probably be how some Winamp plugins are able to just cuttoff the silence at the end of a file during decoding, thus achieving gapless playback. Or isn't that true gapless?

Of course I saw the FAAC source. I understand your feeling to minimize/simplify the problem. But the problem cannot be simplified as you expected. The simplest solution would be something like what I wrote in the previous post, which talented people won't scare.

I didn't doubt you saw the FAAC source, as you specifically mentioned the decoding library used by it and other programs. I just wanted to make sure others reading this thread knew the information was available. My mentioning that I was minimizing the problem was just me apologizing in advance, to ensure no one would take offence to what I was saying. And also talented people may scare if they think that working on this means they themselves must complete it. Publishing the source of whatever they did would be more than good enough. If there is enough interest, others are then able to continue. I think we are putting the cart before the horse though, don't you? After all, this program will be about as popular and useful as your ACMENC and Otto's iTunesencode. Not saying they aren't loved here at HA and other select places on the net, but they are no where near large enough to have their development or developers questioned as to who's working on them and their progress. There really shouldn't be any planning, just us making a thread like this with info, and then down the line if someone ends up working on such an app from what we and hopefully other people write here they can release it to the community. That was the point I was trying to make, just because there's demand, doesn't mean someone who wants such a feature has to make an awesome program, or even little more than a hack. I didn't want people to think I was alluding to that.