> > 2. There are about 15 files that still have trailing whitespace in a > field (yes, I see the `string-trim-right` in the code and do not > understand). I attach a sample.
Sorry, I am an idiot: I am testing emms-info-native--decode-info-fields and you don't trim until emms-info-native. Sorry to waste yr time. ---Fran On Sun, 21 Feb 2021 at 19:14, Fran Burstall (Gmail) <[email protected]> wrote: > Hi, > > Just tried the new version and it works very well except: > > 1. Just one file returns nil: it has a gigantic (4.8MB) id3v2.3 tag which > I can send if you want. Probably I should just accept defeat on this one! > 2. There are about 15 files that still have trailing whitespace in a > field (yes, I see the `string-trim-right` in the code and do not > understand). I attach a sample. > 3. I have 40 files where the date is truncated: emms-info-taglib gives > 2017-10-13 while emms-info-native just gives 2017. Again I attach a sample. > > ---Fran > > > > On Sun, 21 Feb 2021 at 18:20, Petteri Hintsanen <[email protected]> wrote: > >> I just pushed a new revision without emms-info-native--max-peek-size >> checks. It still does a couple of other checks, but you shouldn’t see >> excessive size errors anymore. >> >> > My personal take is that trimming the whitespace is a good idea, if only >> > because other info sources do it. >> >> I added trailing whitespace trimming to all info-fields, including >> Vorbis comments. They are text anyway. >> >> > and similarly for emms-info-taglib. The native took 200 seconds and >> taglib >> > 300 for the 14000 or so files! Looks like not shelling out 14000 times >> > trumps the speed of C++ (at least on my setup where I suspect a lot of >> the >> > time is spent reading the mp3's from the ntfs filesystem they live on). >> >> That’s true, shelling incurs a heavy overhead. >> >> I have compiled taglib shim as Emacs module so that it doesn’t need to >> do any execs. It is, depending on caching conditions (I suppose), about >> 2-10x faster than emms-info-native. >> >> Petteri >> >
