AudioShell is a new
PowerShell-driven interface for converting, tagging and analyzing audio / music files.
edit: Renamed to
PowerShell Audio. There is already an AudioShell out there. Oops!
Stable release 1.2 is now available, which adds AAC and Apple Lossless support under 64-bit PowerShell.
Features:
- A unified interface to popular codecs (Currently Lame MP3, Ogg Vorbis, Apple AAC, FLAC, Apple Lossless, and Wave).
- Fast and highly concurrent ("multi-threaded") for modern, multi-core systems.
- ReplayGain and R128 integration. Batch-analyze thousands of files quickly, then save the results to disk, convert to Apple SoundCheck format, or apply the changes directly during encoding.
- Metadata preservation between formats.
- Import, export and modify cover art.
- PowerShell interface brings powerful integration and scripting capabilities.
- API is open-source and extensible.
With a bit of PowerShell know-how, you can create short scripts to remove the word "The" from artist names, arrange albums in chronological order, and so on.
You can download it here (https://github.com/jherby2k/PowerShellAudio/releases/latest). The installer's source code is also provided. It will install PowerShell 4.0 and .NET 4.5.2 if they aren't already present. If you really don't want to use the installer, there is a .zip download as well.
Here are some simple examples:This command simply converts a folder full of FLAC files into Lame MP3s:
Get-AudioFile *.flac | Export-AudioFile "Lame MP3" -Directory C:\Output
To list all the available encoders:
Get-AudioEncoderInfo
To get the available settings, default settings etc. for Lame:
Get-AudioEncoderInfo "Lame MP3"
All the available cmdlets are documented, so for examples and a list of parameters, use the Get-Help cmdlet:
Get-Help Export-AudioFile -Full
Here are some more advanced examples, which illustrate some of my favorite use cases:Add ReplayGain 2.0 to your entire FLAC library, treating each directory as a separate album:
Get-ChildItem C:\Users\Myself\Music -Directory -Recurse | % { $_ | Get-ChildItem -File -Filter *.flac | Measure-AudioFile "ReplayGain 2.0"
-PassThru | Save-AudioFileMetadata }
Convert your whole FLAC library to VBR AAC, with SoundCheck tags calculated from album ReplayGain information:
Get-ChildItem C:\Users\Myself\Music -Filter *.flac -Recurse | Get-AudioFile | Export-AudioFile "Apple AAC" "C:\Output\{Artist}\{Album}" -Setting @{AddSoundCheck = "Album"} -Name "{TrackNumber} - {Title}"
Convert your whole FLAC library to VBR MP3, with ReplayGain directly applied to the resulting volume levels:
Get-ChildItem C:\Users\Myself\Music -Filter *.flac -Recurse | Get-AudioFile | Export-AudioFile "Lame MP3" "C:\Output\{Artist}\{Album}" -Setting @{ApplyGain = "Album"} -Name "{TrackNumber} - {Title}"
Hope this helps! PowerShell is really wonderful, once you get used to an object-oriented shell.
Interesting to see you are directly using libmp3lame, libFLAC, libVorbis, and especially, CoreAudioToolbox for Apple AAC.
Yes, I really want to ditch the old DOS prompt for good.
Internally, chunks of samples are passed around asynchronously, as 32-bit floating-point data. Metadata is handled in Unicode. And everything is done in-memory (no temp files). That stuff is all pretty hard to do when you're trying to automate the old-school cmd.exe shell.
Also, it was fun working with the different APIs, and the native code interop stuff was pretty challenging, in a good way.
That's some powerful stuff you're working on, mate, thanks!
Updated version 0.9.1:
Added the ApplyGain setting (previously available for the Lame MP3 encoder) to the other lossy formats (Apple AAC and Ogg Vorbis).
No bug fixes, because no one has reported any yet
I've also provided a .zip version for those who don't trust installers (even open source ones). The files need to be placed somewhere in your PSModulePath. You are responsible for making sure .NET 4.5.2 and PowerShell 4.0 or later are present. If you get confused, use the installer. It's very tidy.
I've also provided a .zip version for those who don't trust installers (even open source ones).
Thanks for the zip but it's not matter of trust, I choose to not install anything mainly to keep Windows free of issues over the years.
I've had this conversation few times before, people that create apps take this argument so personally, nothing personal, I like to push for portable versions, all the settings are there, they are efficient, stable and operational in the same way and there is less to do from the user/client. Of course I install software on customers' workstations, I install some on mine too (for example 7-Zip, Chrome, LogMeIn, Office, PDF Printer), I just don't want to install everything, especially for a test.
Not related to this (http://www.softpointer.com/AudioShell.htm) in any way?
No,. I thought I'd checked the name but clearly I didn't . Might change it before 1.0.
Bug fix release 0.9.2:
- Save-Metadata now preserves existing SoundCheck tags unless AddSoundCheck=$false, or a new tag is being generated (MP4 and ID3)
- Save-Metadata now properly updates atoms, instead of just appending new ones (MP4)
- Partial output is now cleaned up correctly on failure
Any feedback guys? I had hoped for greater adoption here... I feel like this tool should replace whatever command-line stuff you're doing now. Let me know what's missing and/or preventing you from switching.
Hi, this looks pretty good. Going to give it a try.
I wonder if LossyWAV support could be a possibility
Let me know what's missing and/or preventing you from switching...
Just guessing from my own state-of-knowledge: Few people know how to use powershell while using a batch file or a command line utility is rather simple...
Maybe some readme / first steps / tutorial / how-to would help.
Is the ReplayGain implementation using EBU R128 or the original algorithm?
Let me know what's missing and/or preventing you from switching...
Just guessing from my own state-of-knowledge: Few people know how to use powershell while using a batch file or a command line utility is rather simple...
Maybe some readme / first steps / tutorial / how-to would help.
Makes sense. Here's a quick primer on some basic PowerShell concepts. Please read through it and tell me what you think! I'm happy to clarify or elaborate as needed.
https://github.com/jherby2k/AudioShell/wiki...werShell-Primer (https://github.com/jherby2k/AudioShell/wiki/PowerShell-Primer)
Is the ReplayGain implementation using EBU R128 or the original algorithm?
Currently implements the original algorithm, or I guess technically an all-new algorithm producing RG 1.0 -compliant results, but somewhat faster by using multiple threads. I'd definitely like to add R128 in the near future.
Let me know what's missing and/or preventing you from switching...
Just guessing from my own state-of-knowledge: Few people know how to use powershell while using a batch file or a command line utility is rather simple...
Maybe some readme / first steps / tutorial / how-to would help.
Makes sense. Here's a quick primer on some basic PowerShell concepts. Please read through it and tell me what you think! I'm happy to clarify or elaborate as needed.
https://github.com/jherby2k/AudioShell/wiki...werShell-Primer (https://github.com/jherby2k/AudioShell/wiki/PowerShell-Primer)
I'm another who is unfamiliar with PowerShell so appreciate the primer. Combine this with a 'man-page' full of practical examples/frequent use-cases and you'll be close to nailing the documentation.
I did, however, run into a problem during use. I maintain three concurrent music libraries; I keep a primary archival FLAC library and transcode to two different Vorbis settings for different devices. I've found that attempting to view AudioShell Ogg Vorbis settings causes it to crash with an 'unable to find libVorbis' error.
I did, however, run into a problem during use. I maintain three concurrent music libraries; I keep a primary archival FLAC library and transcode to two different Vorbis settings for different devices. I've found that attempting to view AudioShell Ogg Vorbis settings causes it to crash with an 'unable to find libVorbis' error.
Having trouble reproducing this.
What's your command line? I'm assuming Get-AudioEncoderAvailableSettingList "Ogg Vorbis"
Can you, after running that command, run $env:PATH and then paste the results here? Specifically, the first part of the path variable should be pointing to where libVorbis is installed. Please look in that location and let me know what you see.
Also, are you on 64-bit windows, and if so, is this 64-bit PowerShell?
I feel like this tool should replace whatever command-line stuff you're doing now. Let me know what's missing and/or preventing you from switching.
Since your cmdlets deal with "AudioFile" objects instead of a simple octet stream of PCM, I guess your cmdlets don't work with any existing solutions such as piping from ffmpeg (can read almost anything) or piping through sox (to do some DSP).
I think this is the most missing feature ... interoperability.
Any solution that can make them work with external commands in some ways would be nice.
Add to that, support for cuesheet would be nice.
You can use a script like this to work with ffmpeg, via a temp file:
$tempFile = tempoutput.wav
Start-Process ffmpeg.exe -ArgumentList "<options> -i input.wav $tempFile" -Wait
Get-AudioFile $tempFile | Export-AudioFile "FLAC"
Remove-Item $tempFile
You can easily send an AudioFile into sox, too. Just not as stdin.
Consider what a "simple octet stream of PCM" is. It's PCM audio without any additional information (bitrate, sample rate, channels etc), disguised as text so cmd.exe can deal with it. That's not elegant, simple or even all that safe. It's definitely not object-oriented, so I don't think it's a good idea.
You did get me thinking again about some sort of low-level API, where you'd pass around SampleCollection objects instead of full AudioFiles. I'll park it for now, though.
Cuesheets, yes. I will log a feature request.
You can use a script like this to work with ffmpeg, via a temp file:
$tempFile = tempoutput.wav
Start-Process ffmpeg.exe -ArgumentList "<options> -i input.wav $tempFile" -Wait
Get-AudioFile $tempFile | Export-AudioFile "FLAC"
Remove-Item $tempFile
You can easily send an AudioFile into sox, too. Just not as stdin.
Oh, I see. I have to say that tempfile is worse than good-old piping, but it should at least work...
Consider what a "simple octet stream of PCM" is. It's PCM audio without any additional information (bitrate, sample rate, channels etc), disguised as text so cmd.exe can deal with it. That's not elegant, simple or even all that safe. It's definitely not object-oriented, so I don't think it's a good idea.
Well, I'm not saying that your software should use PCM instead of AudioFile.
What I was saying is: object-oriented piping has many good points, but it will be poorer in terms of generality/interoperability without sub-channels to support good-old way.
That being said... most software don't actually use raw PCM for piping. What they use is WAV, AIFF or some other proper audio format that wraps PCM.
Therefore, I think most of your description about "simple octet stream of PCM" doesn't hold true there.
ffmpeg even writes tags in some containers, which can be read on the other end point of the pipe, by a program which authors of ffmpeg don't even know.
I did, however, run into a problem during use. I maintain three concurrent music libraries; I keep a primary archival FLAC library and transcode to two different Vorbis settings for different devices. I've found that attempting to view AudioShell Ogg Vorbis settings causes it to crash with an 'unable to find libVorbis' error.
Having trouble reproducing this.
What's your command line? I'm assuming Get-AudioEncoderAvailableSettingList "Ogg Vorbis"
Can you, after running that command, run $env:PATH and then paste the results here? Specifically, the first part of the path variable should be pointing to where libVorbis is installed. Please look in that location and let me know what you see.
Also, are you on 64-bit windows, and if so, is this 64-bit PowerShell?
You assumed correctly:
PS C:\Users\ThinkPad> Get-AudioEncoderAvailableSettingList "Ogg Vorbis"
Get-AudioEncoderAvailableSettingList : The composition produced a single composition error. The root cause is provided
below. Review the CompositionException.Errors property for more detailed information.
1) Unable to load DLL 'libvorbis.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Resulting in: An exception occurred while trying to create an instance of type
'AudioShell.Extensions.Vorbis.VorbisSampleEncoder'.
Resulting in: Cannot activate part 'AudioShell.Extensions.Vorbis.VorbisSampleEncoder'.
Element: AudioShell.Extensions.Vorbis.VorbisSampleEncoder --> AudioShell.Extensions.Vorbis.VorbisSampleEncoder -->
DirectoryCatalog (Path="C:\Program Files\WindowsPowerShell\Modules\AudioShell\Extensions\Vorbis")
Resulting in: Cannot get export 'AudioShell.Extensions.Vorbis.VorbisSampleEncoder
(ContractName="AudioShell.ISampleEncoder")' from part 'AudioShell.Extensions.Vorbis.VorbisSampleEncoder'.
Element: AudioShell.Extensions.Vorbis.VorbisSampleEncoder (ContractName="AudioShell.ISampleEncoder") -->
AudioShell.Extensions.Vorbis.VorbisSampleEncoder --> DirectoryCatalog (Path="C:\Program
Files\WindowsPowerShell\Modules\AudioShell\Extensions\Vorbis")
At line:1 char:1
+ Get-AudioEncoderAvailableSettingList "Ogg Vorbis"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-AudioEncoderAvailableSettingList], CompositionException
+ FullyQualifiedErrorId : System.ComponentModel.Composition.CompositionException,AudioShell.Commands.GetAudioEncod
erAvailableSettingListCommand
Yep, it's 64-bit PowerShell running on 64-bit Windows 8.1.
$env:PATH
C:\Program Files\WindowsPowerShell\Modules\AudioShell\Extensions\Vorbis\x64
Despite the error, a quick glimpse in this directory finds both libogg.dll and libvorbis.dll sitting cosily in C:\Program Files\WindowsPowerShell\Modules\AudioShell\Extensions\Vorbis\x64. Odd.
I toyed a little with MP3 encoding and found that everything worked well except transference of some metadata. Most of my music contains song lyrics stored in the FLAC VorbisComment field UNSYNCEDLYRICS. AudioShell transferred all the main fields but excluded the lyrics field in the sample MP3's tags. Since Vorbis fails, I haven't been able to test the transfer of VorbisComments. I hope this is of help.
Oh also, I wonder whether you could add a list of all AudioShell cmdlets to the primer? Get-help AudioShell lists only two cmdlets so aside from the examples, I'm unsure of AudioShell's scope. It needn't be as detailed; just a simple list of all cmdlets would be incredibly helpful.
Thanks
Found the issue, I think. Thanks for the feedback!
Version 0.9.3:
- Renamed PowerShell Audio from AudioShell, due to a name conflict.
- Added Visual C++ 2012 Redistributable merge module to the installer, since it is a dependency for the native Vorbis libraries.
- Corrected minor issue where the native Vorbis library was being loaded prematurely.
I toyed a little with MP3 encoding and found that everything worked well except transference of some metadata. Most of my music contains song lyrics stored in the FLAC VorbisComment field UNSYNCEDLYRICS. AudioShell transferred all the main fields but excluded the lyrics field in the sample MP3's tags. Since Vorbis fails, I haven't been able to test the transfer of VorbisComments. I hope this is of help. Oh also, I wonder whether you could add a list of all AudioShell cmdlets to the primer? Get-help AudioShell lists only two cmdlets so aside from the examples, I'm unsure of AudioShell's scope. It needn't be as detailed; just a simple list of all cmdlets would be incredibly helpful. Thanks
Right now only a common set of tags are maintained, even from FLAC -> Vorbis. I'll think about adding support for arbitrary tags for the formats which support them (ID3 for example has a fixed set of frame types, and nothing for lyrics AFAIK).
I've added a quick page to the PowerShell Audio wiki (https://github.com/jherby2k/PowerShellAudio/wiki) listing the available cmdlets.
Version 0.9.4:
- ApplyGain=Album now works when track ReplayGain is missing, and vice versa.
- Metadata is now always removed when a field is set to an empty string (""), instead of potentially throwing an exception.
- Corrected a null reference exception in the Vorbis extension (introduced in 0.9.3).
I toyed a little with MP3 encoding and found that everything worked well except transference of some metadata. Most of my music contains song lyrics stored in the FLAC VorbisComment field UNSYNCEDLYRICS. AudioShell transferred all the main fields but excluded the lyrics field in the sample MP3's tags. Since Vorbis fails, I haven't been able to test the transfer of VorbisComments. I hope this is of help. Oh also, I wonder whether you could add a list of all AudioShell cmdlets to the primer? Get-help AudioShell lists only two cmdlets so aside from the examples, I'm unsure of AudioShell's scope. It needn't be as detailed; just a simple list of all cmdlets would be incredibly helpful. Thanks
Right now only a common set of tags are maintained, even from FLAC -> Vorbis. I'll think about adding support for arbitrary tags for the formats which support them (ID3 for example has a fixed set of frame types, and nothing for lyrics AFAIK).
I've added a quick page to the PowerShell Audio wiki (https://github.com/jherby2k/PowerShellAudio/wiki) listing the available cmdlets.
Thanks, the improved documentation is very useful.
As an aside, I used Get-AudioInfo of multiple files. The cmdlet works as expected however it outputs a list of info without file names. A quick check of file sizes will determine which files have been checked but it would be easier if file names were included by default.
As an aside, I used Get-AudioInfo of multiple files. The cmdlet works as expected however it outputs a list of info without file names. A quick check of file sizes will determine which files have been checked but it would be easier if file names were included by default.
Get-AudioInfo returns AudioInfo objects, which contain, well, information about the audio. Really, that cmdlet just returns the AudioInfo property (like calling $audioFile.AudioInfo). I might remove it, because it's a borderline useless cmdlet. AudioFiles also have a FileInfo property ($audioFile.FileInfo), which is what you want to look at.
As an aside, I used Get-AudioInfo of multiple files. The cmdlet works as expected however it outputs a list of info without file names. A quick check of file sizes will determine which files have been checked but it would be easier if file names were included by default.
Get-AudioInfo returns AudioInfo objects, which contain, well, information about the audio. Really, that cmdlet just returns the AudioInfo property (like calling $audioFile.AudioInfo). I might remove it, because it's a borderline useless cmdlet. AudioFiles also have a FileInfo property ($audioFile.FileInfo), which is what you want to look at.
Yeah, I was just toying around to gauge the scope of the program; I tend to use MediaInfo when I need to read audio information.
Version 0.9.5:API Changes- ExtensionProvider is now a static class that includes additional common functionality.
- Moved many properties into new SampleEncoderInfo and MetadataEncoderInfo classes.
- New Get-AudioEncoderInfo and Get-AudioMetadataEncoderInfo cmdlets added.
- Removed some obsolete cmdlets.
- Added Day and Month to standard metadata.
Bug Fixes- Vorbis Comment DATE field is now parsed correctly.
- ExtensionProvider now loads referenced assemblies in the root directory.
Other Changes- Lame extension now uses ReplayGain module for scaling (eliminates redundant code).
- Proper WiX deployment projects added, now that Visual Studio Community Edition supports extensions.
- Added shiny new icons!
Version 0.9.7This is the last API breaking release before 1.0.
API Changes- New Get-AudioAnalyzerInfo cmdlet added (replaces Get-AudioAnalyzerList)
- Minor changes to the GroupToken class, for easier analyzer development
New Features- ReplayGain 2.0 (R128) analysis
Bug Fixes- Resolved crashes when using new cmdlets from a 64-bit process or when missing native libraries
Other- Bootstrap installer now includes the full Visual C++ 2013 Redistributable (required by various native libraries)
edit: Updated to 0.9.7. There was a serious bug in the iTunes metadata encoder that's been there for some time. You should reencode any MP4 files created with any earlier versions. Sorry!
Version 0.9.8This is a "release candidate" for version 1.0, assuming no serious bugs are identified.
Features- Upgraded FLAC extension to version 1.3.1.
- WAVEFORMATEXTENSIBLE wave files can now be read.
- Types returned by cmdlets are now serializable.
Bug Fixes- MP4 ©day atom now handles the full date, instead of just the year.
Version 1.0.0 - First production-ready release!
Bug fixes- Better parsing of MP3s with "false syncs" due to cover art or other metadata.
For version 1.1, I'm focusing on cover art support.
I know the name AudioShell was already addressed but I back in the day an HA member (IIRC, possibly, it was Jan) also had a small program named AudioShell that allowed you to change the default audio icons in WinXP. I actually got a little excited that perhaps there was a new version to address Win7/8!
Hi Jebus,
thanks for your work on PowerShell Audio.
I created an entry in the Hydrogenaudio Wiki. Link (http://wiki.hydrogenaud.io/index.php?title=PowerShell_Audio)
As a Logo I used the Icon of your executable. Hope that is fine with you.
Please tell me if you have any corrections or additional infos.
Thanks for developing this tool, it seems promising.
Can someone tell me the proper command line to add SoundCheck to m4a files that already have Replaygain?
Get-AudioFile "input.flac" | Measure-AudioFile "ReplayGain" -PassThru | Save-Metadata
When I try to use this command from the Primer I get the following error.
The term 'save-metadata' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.At line:1 char:69
+ get-audiofile .\b.flac | measure-audiofile "replaygain" -passthru |
save-metadat ...
+
~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (save-metadata:String) [], Comma
ndNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Get-AudioFile "input.flac" | Measure-AudioFile "ReplayGain" -PassThru | Save-Metadata
When I try to use this command from the Primer I get the following error.
The term 'save-metadata' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.At line:1 char:69
+ get-audiofile .\b.flac | measure-audiofile "replaygain" -passthru |
save-metadat ...
+
~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (save-metadata:String) [], Comma
ndNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
After comparing the Primer with your simple examples in the post it looks like Save-Metadata should be updated to Save-AudioMetadata in the Primer.
Hi Jebus,
thanks for your work on PowerShell Audio.
I created an entry in the Hydrogenaudio Wiki. Link (http://wiki.hydrogenaud.io/index.php?title=PowerShell_Audio)
As a Logo I used the Icon of your executable. Hope that is fine with you.
Please tell me if you have any corrections or additional infos.
Thanks! Can you please edit the sidebar to indicate the license is
LGPL? I already updated the text.
There is no reponse ? waiting here...
Version 1.1:
Highlights- Cover art is now persisted during conversions.
- Cover art can be extracted from file metadata, and/or loaded from external bitmap, JPEG and PNG files.
- Cover art can be saved to a file as metadata, and/or exported to .png or .jpg image files.
- For compression purposes, cover art images can be converted to JPEG format and/or resized.
- Expanded Get-Help documentation for cmdlet parameters.
New Cmdlets- Clear-AudioFileMetadata
- Convert-AudioCoverArt
- Convert-AudioFileCoverArt
- Export-AudioCoverArt
- Export-AudioFileCoverArt
- Get-AudioCoverArt
- Get-AudioFileCoverArt
- Set-AudioFileCoverArt
Cmdlet Changes- Get-AudioMetadata was renamed to Get-AudioFileMetadata
- Save-AudioMetadata was renamed to Get-AudioFileMetadata
- Set-AudioMetadata was renamed to Set-AudioFileMetadata
- Many cmdlets that require an output directory have had their syntax changed, and now recognize the current directory and relative paths.
Thanks for developing this tool, it seems promising. Can someone tell me the proper command line to add SoundCheck to m4a files that already have Replaygain?
How do they already have ReplayGain stored? In an embedded ID3 tag? There is no atom for ReplayGain as far as I know.
Right now embedded ID3 tags are skipped. I could parse them if it's a useful feature.
In m4a files, aacgain, Winamp and foobar2000 write APE tags, according to http://wiki.hydrogenaud.io/index.php?title=ReplayGain (http://wiki.hydrogenaud.io/index.php?title=ReplayGain)
OK, i'll look into adding an APE reader at minimum to the next version. I don't think I want to include a writer though, since it's technically incompatible the MP4 specification. Maybe for MP3.
How do they already have ReplayGain stored? In an embedded ID3 tag? There is no atom for ReplayGain as far as I know.
Right now embedded ID3 tags are skipped. I could parse them if it's a useful feature.
They are in APE tags generated by Foobar2000.
One more question. Is there a way to calculate and apply Soundcheck without converting from Replaygain?
Not sure I understand what you mean. You have to calculate using the ReplayGain or the ReplayGain 2.0 (R128) algorithm. The algorithm Apple uses is proprietary (and doesn't support album gain, so IMO it isn't as good). If you use something like this, on an .m4a file:
$audioFile | Measure-AudioFile "ReplayGain 2.0" | Save-AudioFileMetadata -Setting @{AddSoundCheck = "Album"}
You are going to get SoundCheck tags, based on R128 analysis, on a per-album basis. No ReplayGain tags.
Version 1.2.0 is out, with 64-bit AAC and Apple Lossless support. Previously you had to run under a 32-bit PowerShell prompt for these extensions to work. iTunes 12 shipped with 64-bit support libraries, so this is now possible.
This version also targets .NET 4.6, and some support libraries were recompiled. Basically, this is a maintenance release beyond the above.