dsf (DSD/Direct-Stream Digital) - ID3v2.3 tag.wav - ID3v2.3 tag in 'id3 ' RIFF chunk and LIST INFO chunk.mpc, mp+, monkey’s audio, wav pack, optim frog, true audio - APE tags, APEv2 tags.
ogg, flac, opus, speex (vorbis comment tags).Apple iTunes aac (m4a, m4p, m4r and m4b) and mp4 and aiff files.Unless anyone can suggest an elegant solution (either force TagLib# to write a new ID3v2.3 block or stop FFmpeg from writing one at all) I think I may just programmatically remove the ID3v2.4 block from the file after encoding and then write a new one.AudioShell is a Windows Explorer extension which enables viewing and editing of ID3 and other tags.Įxplorer may be able do some of this all ready, depending on your version of Windows and the applications you've installed, but AudioShell takes the idea further by supporting all these audio and tag formats. When using the TagLib# on this untagged file, the tags were correctly applied (v2.3) and it continued to play properly in our software as well as others. One other thing I tried was to rip out the ID3v2.4 block completely after the re-encoding, this plays (as you'd expect) in all media players. Using another tool to change the ID3 tags (in this case AudioShell Tag Editor) and add the same album art changed the ID3 version to 2.3 and meant that the mp3 played on our softwares audio player as well as other media players - However changing the tags afterwards produces an exception when saving the image. Using TagLib# in our software to add album art keeps ID3v2.4 but the tags are only available using TagLib# to read them and it only plays in media players such as Windows Media Player. This initial re-encoded file plays fine in media players and our software. After re-encoding with FFmpeg, the ID3 data is v2.4. Andrew Laughlin's advice I've been looking at the differences of the ID3 tags in the hex of each file. My largest problem here is that I don't know whether the fault lies with (our implementation of) FFmpeg (large library that's used fine in many other places), TagLib-Sharp or the audio playing.Įdit 1: Following J. To change the ID3 tags we have started using TagLib-Sharp and the code for changing the ID3 tags is: public void SetId3Tags(string path, Bitmap image, IDictionary values)įileInfo.Attributes = FileAttributes.Normal Process p = Process.Start(FFmpegProcessInfo) ProcessStartInfo FFmpegProcessInfo = new ProcessStartInfo() įFmpegProcessInfo.WorkingDirectory = workingDirectory įFmpegProcessInfo.FileName = "ffmpeg.exe" įFmpegProcessInfo.Arguments = "-i \"" + inFile + "\"" + " -ar "+SAMPLE_RATE + metadata + "\"" + outFile + "\"" //default conversion to SAMPLE_RATEįFmpegProcessInfo.CreateNoWindow = true //hide from userįFmpegProcessInfo.RedirectStandardError = true įFmpegProcessInfo.RedirectStandardOutput = true įFmpegProcessInfo.UseShellExecute = false String workingDirectory = Environment.CurrentDirectory String metadata = (inFile.EndsWith("mp3")) ? " " : " -map_meta_data 0:0 " OutFile = Path.ChangeExtension(outFile, "mp3") The code for using FFmpeg from our software is as follows: private const string SAMPLE_RATE = "44100" Changing tags on mp3s from other sources or those that have already got ID3 tag album art is fine. This problem only seems to occur when changing a newly converted mp3s' ID3 tags after using FFmpeg. It also seems that Windows cannot pick up the values of the ID3 tags in explorer, but Windows Media Player will still play the track. The track will not play audio in our software.
Whilst the conversion works fine and the mp3 files work on our hardware afterwards, we're having issues specifically when adding an album art to the ID3 tags of the mp3. Recently we've started using FFmpeg to convert a number of different audio types to mp3 to allow them to be imported and used on our hardware. Due to hardware restrictions, the software we produce tries to ensure that any audio file it imports into it's library (ready to be copied onto the hardware) is an acceptable bit rate.
0 kommentar(er)
