Version: (using KDE KDE 3.2.1) Installed from: Debian testing/unstable Packages Compiler: gcc (GCC) 3.3.3 (Debian 20040320) OS: Linux I extracted MP3 files using variable bit rate (VBR) encoding without bit rate limits. As a result I got MP3-file having incorrect (or non-existent) Xing-VBR tag. To verify faulty VBR tagging I load resulted file into easytag (0.30d) which shows the bitrate of the first chunk instead of average rate. Also XMMS (1.2.10) shows play length incorrectly for the produced file (play length changes when playing). If I try to produce the same file manually using cdparanoia and lame (3.95) by command "lame -V4 source.wav dest.mp3", the resulted file is correct. Audiocd MP3 settings I am using: Encoding Method: Variable Bitrate, Joint Stereo, Quality 4 (5th from left) Options: Original, Error Protection, Write ID3 Tag Variable Bitrate Settings: Write Xing VBR tag, (Minimal, maximal, Average unselected) Filter Settings: all unselected If I experiment with settings "Write ID3 Tag" and "Write Xing VBR tag" file is still incorrect. This is merely a wishlist bug for me, but I believe it is normal bug for most users.
I think the problem is in liblame btw, rm your lame. use version 3.90.3 http://www.rarewares.org/files/mp3/lame-3.90.3-linux-bin.tar.bz2 http://www.rarewares.org/files/mp3/lame-3.90.3-linux.tar.bz2 see http://www.hydrogenaudio.org/index.php?act=SF&s=&f=15
Thanks for your comments Nick, but you provide no light to the matter. I'm not sure whether I stated my problem clearly enough, so I repeat it (using other words): I was using audiocd-kio-slave by konqueror to extract/rip MP3-files. That is writing "audiocd:" to location bar and then copying MP3-files from it into another filemanager window. Resulted files have no Xing-VBR tag set. Lame command itself works as expected when using from shell. You suggested that liblame could be problem, but my test with older version of lame (3.90.1) provided the same error. > http://www.rarewares.org/files/mp3/lame-3.90.3-linux-bin.tar.bz2 Packet above does not have liblame! > http://www.rarewares.org/files/mp3/lame-3.90.3-linux.tar.bz2 Is that source somehow tweaked, since it didn't compile on the same environment where offcial lame sources compile. > see http://www.hydrogenaudio.org/index.php?act=SF&s=&f=15 Link above has forum having hundreds of messages. If there is info about the issue could you be more specific.
I have the exact same problem. I am using Lame 3.90, compiled myself.
On Wednesday 19 May 2004 11:04, Sander Alberink wrote: > 10:04 ------- I have the exact same problem. I am using Lame 3.90, compiled > myself. I consulted the same bug in the lame BBS, they instructed that libmp3lame.so is used incorrectly. After the encoding lame_mp3_tags_fid(...) should be called and parameter should be regular file. I believe that kio-audioslave lame-plugin does not do this or issues it against KIO::SlaveBase which is not regular file. I am currently too unexperieced to trace/fix this for myself.
I am not sure if this is related, but when I encode mp3 files using the audiocd kio-slave they come out broken.It seems like there is an issue with writing the id3 tags (the audio slave should really support id3v2 tags btw). Settings: stereo, vbr, quality high, original, write id3, write xing tag. Using KDE 3.2.92 from SUSE RPMs. Effect: When I drag an mp3 file from the audiocd:/MP3 directory to another location, everything works fine. The file plays correctly in all players. However testing the file with mpg123 -v -t results in an error message: mpg123 -v -t file.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59s-mh4 (2000/Oct/27). Written and copyrights by Michael Hipp. [...] MPEG 1.0, Layer: III, Freq: 44100, mode: Stereo, modext: 0, BPF : 104 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 32 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 18952 [ 4], Time: 08:15.07 [00:00.10], Bitrate 128Illegal Audio-MPEG-Header 0x5441474c at offset 0x78e5be. Found old ID3 Header Frame# 75828 [ -1], Time: 33:00.81 [00:00.00], Bitrate 32 When ripping the same file from the wav directory and encoding with lame -v -q 1 -m s --add-id3v2 mpg123 does not report any errors. Lame is LAME version 3.95 MMX I experimented with the settings (killing kio_audiocd between runs) and found out that unchecking write xing tag or changing the bitrate settings had no effect. When I unchecked write id3 tag, kde would not encode the file anymore. (Error message could not read file.mp3. encoding failed).
I have fixed the issue with unchecking writing id3 tags in 3.3 and head
Ok I see how lame_mp3_tags_fid is called wrong, but for the life of me can't get it to work right. Maybe I am missing something, the docs weren't very explicit. :( Any links?
I guess it has to do with lame_encode_finish, which is obsolete. According to lame.h this call order might work: lame_encode_flush() lame_mp3_tags_fid() lame_close() From lame.h: /* * OPTIONAL: * lame_mp3_tags_fid will append a Xing VBR tag to the mp3 file with file * pointer fid. These calls perform forward and backwards seeks, so make * sure fid is a real file. Make sure lame_encode_flush has been called, * and all mp3 data has been written to the file before calling this * function. * NOTE: * if VBR tags are turned off by the user, or turned off by LAME because * the output is not a regular file, this call does nothing */ void CDECL lame_mp3_tags_fid(lame_global_flags *,FILE* fid); /* * REQUIRED: * final call to free all remaining buffers */ int CDECL lame_close (lame_global_flags *); /* * OBSOLETE: * lame_encode_finish combines lame_encode_flush() and lame_close() in * one call. However, once this call is made, the statistics routines * will no longer work because the data will have been cleared, and * lame_mp3_tags_fid() cannot be called to add data to the VBR header */ int CDECL lame_encode_finish( lame_global_flags* gfp, unsigned char* mp3buf, int size );
One thing is that this isn't a regular file so you can't pass _lamelib_lame_mp3_tags_fid the file
I think the only way to fix this is to: 1) remove xing option 2) dump to a temporary file first so that one function can run and then dump it all through kio. I don't like either option at all.
Benjamin Meyer wrote: > 1) remove xing option > 2) dump to a temporary file first so that one function can run and then > dump it all through kio. Option 1 would render this plugin quite handicapped, since you could no longer output VRB MP3s. However this could be good workaround, since most users still seem to stick to the CBR and those who want better quality use ogg or other tools. I don't know whether option below is possible or requires changes in kde kio core. 3) Ask a file handle trough kio and perform _lamelib_lame_mp3_tags_fid operation against in. If kio can't give a file handle (in case of networked protocol) fallback into case 2.
Yes I agree #1 would be horrible. #3 isn't possible, so I will look into #2
Just bumping up the severity...
Is there any activity on fixing that one ? Best Regards Michael
Yup, it will be resolved for 3.5
SVN commit 417210 by bmeyer: Completely new mp3 (lame) encoder that uses KProcess and outputs the results to a temorary file so *finally* the Xing tag can be set. This is also the beginings of the new encoder(s) for audiocd which will finally produce the merger of KAudioCreator and audiocd (and perhaps Juk?). BUG:79235 M +216 -527 encoderlame.cpp M +36 -35 encoderlame.h
*** Bug 107456 has been marked as a duplicate of this bug. ***
For those who has a lot of mp3s with this error, this program claims to fix them: http://www.willwap.co.uk/Programs/vbrfix.php I've yet to try it myself, but I will since I have 3000+ songs ripped with KDE 3.4 that contains this error.