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?

[Otto42]

Short answer: no.

Long answer: yes, but I'm not going to add it to iTunesEncode for a number of reasons:

1) iTunesEncode is designed to just be a CLI to access the functionality that iTunes itself provides via the COM interface, with regards to encoding. Other than copying the resulting encoded file around and renaming it, the file itself is never touched by iTunesEncode. It doesn't do anything at all with the actual data in the file, so adding that sort of functionality is beyond the scope of what iTunesEncode currently does.

2) I lost the source code to iTunesEncode via an accident, and so what you get is what there is. Yeah, I could rewrite the missing pieces easily enough, but there's no real compelling reason to do so at this point. I have already added all the functionality I could feasibly add via the iTunes COM interface. Supposedly, the new iTunes will support VB scripting, which might be advantageous to use in some way, but COM is basically a dead end as far as new functionality goes.

Honestly, it makes more sense to make a new program to modify existing iTunes created AAC files to add that info, sort of thing.

This post has been edited by Otto42: Jun 21 2005, 18:28

[saratoga]

Short answer: no.

Long answer: yes, but I'm not going to add it to iTunesEncode for a number of reasons:

1) iTunesEncode is designed to just be a CLI to access the functionality that iTunes itself provides via the COM interface, with regards to encoding. Other than copying the resulting encoded file around and renaming it, the file itself is never touched by iTunesEncode. It doesn't do anything at all with the actual data in the file, so adding that sort of functionality is beyond the scope of what iTunesEncode currently does.

2) I lost the source code to iTunesEncode via an accident, and so what you get is what there is. Yeah, I could rewrite the missing pieces easily enough, but there's no real compelling reason to do so at this point. I have already added all the functionality I could feasibly add via the iTunes COM interface. Supposedly, the new iTunes will support VB scripting, which might be advantageous to use in some way, but COM is basically a dead end as far as new functionality goes.

Honestly, it makes more sense to make a new program to modify existing iTunes created AAC files to add that info, sort of thing.

How would you get the encoder delay out of iTunes though? Unless it'll give you the exact sample length of the origonal CD Audio track, I don't see how you could calculate it.

[Gabriel]

How would you get the encoder delay out of iTunes though?

Delay is usually constant for an encoder, so you can check it manually once, and you are fine.
However to compute padding value, you have to know the original number of samples.