ALAC Encoder {implemented with a third-party plug-in by thinktink}

[MrSinatra]

Version 1.1.2.21 now available.

Changes:

• Code optimizations for the m4a container.
• Memory utilization optimizations for the m4a container and encoder.
• Minor code optimizations for code shared between the caf and m4a containers.

Last night I bench-marked some of the code and found nothing really horrendous with my code, at least relative to the encoding call. The actual encoding function call was the speed bottleneck.

But, while I was at it I figured I'd get something in there to help things along so I optimized as much as I practically could anyways.

I'm not sure you'll actually see a difference in speed, especially with standard length music files. But maybe somebody somewhere will see an improvement.



Download.

[EDIT/]
I also tested with DiskWrite (don't know why I missed to check that) and everything seems fine with it.

i just wanted to thank u again.

is this available anywhere? via dropbox perhaps?

[cacafuti8888]

Hi, i've got this file in my computer i've downloaded from here months ago, i hope this is what you're looking for.

https://www.dropbox.com/s/3kvx1w1lwba8mi1/BogProgAlacEncoding1_1_2_21Setup.zip?dl=0

[MrSinatra]

hi, thx, yes i already had it, but i just hoped he had it back up in case i install elsewhere remotely, so that helps, thx.

[thinktink]

Attached.

[MrSinatra]

odd Q for you...

i noticed an issue where windows explorer, for any m4a, could have data divergent from "normal" atom tags and i couldn't understand it. the answer seems to be that windows uses "normal" atoms, but ALSO creates a custom moov.udta.Xtra atom and sticks a data blob in there, with what i believe is a WMA style WM tag; odd & bizarre, but NOT out of m4a spec. among the fields win exp uses in this blob, is one for ratings, that win exp can see:

https://community.mp3tag.de/t/no-support-for-reading-windows-explorer-ratings-in-m4a-mp4/15671

http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=76321

http://forums.winamp.com/showthread.php?t=376798

this i think is relevant to you (& me!) if say you have a rated FLAC, and you want to transcode it to ALAC m4a, b/c you want the tag info to also go with the transcode.

Media Monkey solved the issue years ago, (i reported it), by basically updating/saving both sets of tags simultaneously. yes, its duplicative, but it keeps info from being divergent and it also makes the info exposed in windows explorer:

http://www.ventismedia.com/mantis/view.php?id=12017

any chance you could fool around with this and get it to work with your plugin?

also, i think the media monkey solution needs to be adopted by winamp as well, esp for the ML, so that ratings and other tags don't become divergent.

[thinktink]

odd Q for you...

i noticed an issue where windows explorer, for any m4a, could have data divergent from "normal" atom tags and i couldn't understand it. the answer seems to be that windows uses "normal" atoms, but ALSO creates a custom moov.udta.Xtra atom and sticks a data blob in there, with what i believe is a WMA style WM tag; odd & bizarre, but NOT out of m4a spec. among the fields win exp uses in this blob, is one for ratings, that win exp can see:

https://community.mp3tag.de/t/no-support-for-reading-windows-explorer-ratings-in-m4a-mp4/15671

http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=76321

http://forums.winamp.com/showthread.php?t=376798

this i think is relevant to you (& me!) if say you have a rated FLAC, and you want to transcode it to ALAC m4a, b/c you want the tag info to also go with the transcode.

Media Monkey solved the issue years ago, (i reported it), by basically updating/saving both sets of tags simultaneously. yes, its duplicative, but it keeps info from being divergent and it also makes the info exposed in windows explorer:

http://www.ventismedia.com/mantis/view.php?id=12017

any chance you could fool around with this and get it to work with your plugin?

also, i think the media monkey solution needs to be adopted by winamp as well, esp for the ML, so that ratings and other tags don't become divergent.

So I just took another look at the encoder plugin source code. Nowhere in there do I add or modify file metadata except to annotate the (I think required) encoder and codec version strings. Winamp writes the other tags after transcoding with the input plugin that's handling/playing it. Tag writing is done with input plugins, not an encoder plugin. This plugin is purely an encoder plugin. You'd have to ask the Winamp developers to do that.

[MrSinatra]

I can help you with using libmp4v2 to encode the ALAC file to mp4/m4a if you want. just e-mail me

Well I'll be damned, I didn't even see libmp4v2.dll. Looking at the exports I imagine it's far better than what I'm doing. Does it support in-memory reading/writting?

Fantastic!

Is this with winamps library, or your own implementation?

Did you get in touch with Benski?

I posted this thread to the fb winamp group.

I don't actually have a full implementation of the full ISO standard, just a basic hierarchical class handler to help me organize and construct the Moov box piece by piece. Once everything is in place, I call a single function which then triggers callbacks that outputs the data in it's proper order. All I had to do was update the class handler to support 64 bit boxes. I never did contact Benski as my preliminary research into libmp4v2 revealed that it seems to exclusively deal with files already on the drive, which doesn't work very well for a standard Winamp encoder. If memory serves, DrO described one of the encoders that ships with Winamp that just outputs dummy data to Winamp and writing the actual file contents to a temporary location and then swapping the file in once the data is finalized, I'm guessing that encoder uses the libmp4v2 library.

i realize i probably misunderstand / don't know how things work under the hood, but you are saying that when transcoding, your encoder isn't creating the m4a container, but rather the winamp libmp4v2.dll is? i was under the impression your encoder was standalone in that regard.

i would like to see all the apps that make m4a tags include WM tags and windows file property attributes, so everything is congruent; but i doubt this niche issue will get attention from winamp anytime soon.

[thinktink]

... i was under the impression your encoder was standalone in that regard.

...

For the initial m4a container creation, yes. However, there is no facility in the encoder API to receive metadata that I am aware of. Metadata is exclusively handled by input plugins, which is actually a smart move since if there was more than one handler things could get messy. I never did use libmp4v2.

[MrSinatra]

interesting... so if i use winamp to transcode a FLAC to ALAC using your encoder, should i expect Vorbis tags to xfer (and become m4a tags), and if so, how is their input plugin invoked to do it?

[thinktink]

interesting... so if i use winamp to transcode a FLAC to ALAC using your encoder, should i expect Vorbis tags to xfer (and become m4a tags), and if so, how is their input plugin invoked to do it?

As far as the exact structure and program flow for how Winamp determines which input plugin to use to write metadata tags I don't know. I do know that Winamp finds the input plugin that is able to play the file and tells that plugin to write the metadata tags when it's done transcoding and finalizing the file. Winamp gathers the original file's metadata from the input plugin that handles the original file's playback and then sends it to the new file's input plugin. Encoders themselves do not "transcode" files, Winamp does. Winamp coordinates everything from using the original file's input plugin to convert it to the raw PCM data, then Winamp directs the encoder plugin to encode the raw PCM data to the new codec, then using the new file's input plugin to write the metadata after encoding is complete.

[thinktink]

..., should i expect Vorbis tags to xfer (and become m4a tags)...

I really don't know what you should expect since I didn't create the input plugin that plays ALAC files. All I did was make a Winamp compatible encoder.

[MrSinatra]

i gotcha... so if i understand you correctly now, ur saying that if there is any xfer of tags during a transcode, from one format to the next, it is not handled by the encoder, but rather by the input plugin (that also handles playback) for that new format, once the new file is created, and the encoder phase of the operation is complete, and over and done with.

sound right?

my confusion was that i just figured the encoder did more than just create the new tag or container as a blank, but i can see now the elegance of doing it this way.

[thinktink]

i gotcha... so if i understand you correctly now, ur saying that if there is any xfer of tags during a transcode, from one format to the next, it is not handled by the encoder, but rather by the input plugin (that also handles playback) for that new format, once the new file is created, and the encoder phase of the operation is complete, and over and done with.

sound right?

Yes.

[MrSinatra]

I love this encoder!

[MrSinatra]

do u think this will work in 5.9? do u think winamp will try to replace it with their own in house ver? (yours works great for me in 5.8!)