Updated in_mad Winamp MAD MP3 input plugin

Topic: Updated in_mad Winamp MAD MP3 input plugin (Read 300815 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Updated in_mad Winamp MAD MP3 input plugin

Reply #175 – 2006-09-07 11:05:49

The dots are displayed when characters not in the current windows ANSI code page (or libid3tag conversion page) are converted from Unicode. If in the latest release now, when you load the tag editor they are display correctly, but not in Winamp Media Library or Playlist Editor, I'll have to have a look at the interface code to Winamp.

I've had a trial look at converting the entire plug-in to a Unicode implementation, but this requires a LOT of work, but it would solve your problem within the plug-in. I'm going to add the Unicode Winamp DLL interfaces so will be ready for a Unicode winamp.

I'm also getting ready for help adding language translations.

Updated in_mad Winamp MAD MP3 input plugin

Reply #176 – 2006-09-08 10:57:25

I've uploaded another update, this includes some EQ presets, and winampGetExtendedFileInfoW for Winamp to get Unicode tags.

Download from the usual place.

@hat3k, If you could see if this solves your problem, then I'll write in the other Unicode extended file routines.

If anyone wants to have a go at language translations, load "resource.rc" up in a trusty text editor, and change everything thats in English to desired language. If you do have access to a proper resource editor, you can change the language codes too, but as long as you note what language it is in somewhere I can make the changes when I collect all the translations together. I'm going away for the weekend, so I'll collect and sort them out after then.

Cheers for everyones help, bug finding and suggestions.

Updated in_mad Winamp MAD MP3 input plugin

Reply #177 – 2006-09-08 21:14:46

I think it would be helpful to say what heppens when certain things are disabled. ie. detect unknown streams, disabling title streaming, etc.

ID3v2 year display (simple mode)
ZOBS, TYER, \0 1 9 9 7 (switching from advanced to simple and back erases this tag!!) and simple mode does not display the year
year is also stored TDRC, iso8859, 1997; this also does not show in simple mode
mp3infp shows the year in its year field just fine
The 'advanded' button is convienient, but I think it might be having a few issues. If I change advanced/simple tag mode in the main config, it doesn't lose that year tag of mine.
Wouldn't hurt if the 'advanced' button was independent of the other (ape/id3v2 depending) and didn't set the 'default' view as defined in the main decoder config.. just my thoughts.

When I read my lame mp3 files with lametag, replaygain shows as <not stored>, it does not say 0dB. I would think they would be stored differently, but I surely don't know. Anyways, the RGless preamp is still not being applied to my RGless lame mp3 encodes.

"XING VBR seeking using table implemented" Doesn't seem to be working, in_mpg123 is right on with my test vbr file.

Tested for streaming... The input buffer remains full, while the output buffer remains extremely low. Many many many buffer errors reported, along with the usual sync errors from my vbr test stream. Still, disabling shoutcast title support fixes the sync error problem. If the output buffer ever manages to fill, then the buffer errors go away, but this seems to take a while if it happens at all. (ok, I just watched the output buffer fill up then drop all the way back down )

No CPU usage problems here

I don't like the amount of negativity in this post.. This thing is wonderful anyways! Keep it up.

Updated in_mad Winamp MAD MP3 input plugin

Reply #178 – 2006-09-10 18:11:08

Is it just me getting skips from time to time? I just noticed twice - At first I just thought it was an error in my mp3-file. (Edit: It doesn't happen often - maybe for every 5-6th file, but it sounds like it skips a frame) Edit: Nevermind, it WAS errors in the files

Also I think CPU usage of 10-18% is kinda much - for a decoder (on my 4800+ X2). Try decoding a file with in_mad and afterwards with in_mp3 - in_mad is 5-6x for decoding where in_mp3 decodes as a lightning strike!

But BIG thumbs up for the EQ now with presets - It's REALLY cool!!

Updated in_mad Winamp MAD MP3 input plugin

Reply #179 – 2006-09-10 18:35:55

Ok, I'm back. Looks like some heavy beta testing!

First thing, the buffering, I think I'm going to take the main functional decode sections (because they work) and tear the rest apart. I've only been "patching" from 0.14.1b, and as such its now time for a rethink.

The ZOBS TYER problem is due to libid3tag automatically upgrading an ID3v2.3 tag to an ID3v2.4, where TYER is an obsolete tag and is removed and replaced by a TDRC frame. I typo'd in TDRL not TDRC in my code, so that's fixed - but TYER will still be removed. I'll probably add an ID3v2.3 compatability mode.

The lame tag problem has been properly solved now, will be in next update I promise .

The XING VBR seeking probably isn't that accurate still, but at least now it uses the tables, before it completely ignored them! I'll get round to that.

CPU issues.....I'm still a bit worried, as odyssey said, its high - but is it due to libmad naturally? or how the plugin is handling the buffer? I don't know.

If I rethink the decoding loop as a priority - hopefully that will clear usage issues, then start on the rest.

Updated in_mad Winamp MAD MP3 input plugin

Reply #180 – 2006-09-10 18:54:37

Quote from: odyssey on 2006-09-10 18:11:08

Also I think CPU usage of 10-18% is kinda much - for a decoder (on my 4800+ X2). Try decoding a file with in_mad and afterwards with in_mp3 - in_mad is 5-6x for decoding where in_mp3 decodes as a lightning strike!

Well, the pure decoder surely doesn't cause such a high CPU load. I'm running in_mad on a P4 2.6 ghz, the CPU usage varies between less than 1% and 4%, even while using a slightly animated modern skin. With the internal equalizer and dithering as well as noise shaping enabled (commonly i don't use these options) the task manager shows a CPU load that stays a bit closer to 4% than with these options disabled. Nothing really spectacular, therefore there must be something else wrong on your machine.

Quote

CPU issues.....I'm still a bit worried, as odyssey said, its high - but is it due to libmad naturally? or how the plugin is handling the buffer? I don't know.

Obviously it can't be libmad generally that's causing the issues concerning the CPU, 'cause in my case in_mad...

Quote

...decodes as a lightning strike!

I wonder whether some other winamp plugin interferes with the functionality of in_mad on odyssey's machine. Maybe DSP or a software resampling plugin?

Edit: Removed "surround sound plugin" since that's the same like a "DSP plugin". Stupid...

Updated in_mad Winamp MAD MP3 input plugin

Reply #181 – 2006-09-10 20:35:12

Admitted I used a DSP, but without in_mad still takes 4-8% CPU power - quite much on this kind of CPU! in_mp3 uses 1-5% actively, but I don't think we can base the performance on active CPU measurements.

Quote from: Junon on 2006-09-10 18:54:37

therefore there must be something else wrong on your machine.

You need to prove your claims - Why would one plugin work fine and another conflict with things on my machine?? Try my test using the diskwriter output or some null plugin to see the decoding speed.

Updated in_mad Winamp MAD MP3 input plugin

Reply #182 – 2006-09-11 02:24:07

I've uploaded an update, with the changed decoding and buffering loop. I've taken each main section, and re-wrote it into a new loop.

A quick and not very accurate test of disk writing times shows the new in_mad to be approx 0.8x speed of in_mp3. The old one roughly tested to be 0.6x.

These are no measure of speed, but I can say that my machine sees an improvement, hopefully you'll all experience the same. Then again, mine had an improvement when everyone else had 99% CPU usage!

Cheers for all comments in advance!

Updated in_mad Winamp MAD MP3 input plugin

Reply #183 – 2006-09-11 10:58:50

Quote from: odyssey on 2006-09-10 20:35:12

You need to prove your claims[...]Try my test using the diskwriter output or some null plugin to see the decoding speed.

It's not a claim, it's a suspicion. Since the pure in_mad decoder isn't much slower than in_mp3 (in a quick diskwriter test i measured 6 seconds for in_mp3 and 7 seconds for in_mad, tolerance + - 1 second due to inaccuracies caused by using my watch for measuring) the problems you experience might indeed be caused by some unknown problem which has to be found to be able to fix it. Your machine should perform much faster than mine, due to its better processor power, therefore there must be a certain issue that wasn't mentioned in this topic yet. That's why i suspected another plugin to interfere with in_mad's functionality. As you admitted yourself, an active DSP plugin falsified your results.

Quote

Why would one plugin work fine and another conflict with things on my machine?

Maybe due to a decoding bug in libmad that isn't present in the Fraunhofer software used by in_mp3. This bug could cause further issues when the decoded data's being processed in certain output or DSP plugins. But judging by the data you mentioned above, this isn't the case. 4% till 8% without DSP is still noticeably much for an Athlon 64 X2 4800+.

Updated in_mad Winamp MAD MP3 input plugin

Reply #184 – 2006-09-11 11:35:09

In defence of in_mad, and how the decoding loop works, several things could be causing these differences in CPU usage.

I assume we're all using Windows XP. How different operating system schedulers handle threads is an issue. The 99% CPU issue was solved by reinserting a Sleep(20) command (I'd removed it, believing it to be pointless waiting around) - effectively putting in_mad decode thread to sleep for 20ms, I assume allowing other threads in the system to run properly, otherwise in_mad kept looping (under certain circumstances) running at full CPU usage. "Background" tasks, will also change how much process time in_mad has.

A quick note about in_mp3, its default decode thread priority is Highest, where in_mad is Normal. I haven't tried increasing in_mad to Highest priority setting, or decreasing in_mp3 to Normal, but these will again have an impact on CPU usage and decoding speed.

A DSP plug-in (and any extra processing by in_mad) will contribute to an increased CPU load, but I don't think CPU values are anything accurate to go by, it varies between systems, CPU, memory, background workload etc.

Updated in_mad Winamp MAD MP3 input plugin

Reply #185 – 2006-09-11 11:54:05

Quote from: MoSPDude on 2006-09-11 11:35:09

A quick note about in_mp3, its default decode thread priority is Highest, where in_mad is Normal. I haven't tried increasing in_mad to Highest priority setting, or decreasing in_mp3 to Normal, but these will again have an impact on CPU usage and decoding speed.

Thanks for that clarification. I haven't noticed the differences regarding thread priorities in both plugins so far. Would make sense for the people experiencing performance issues to test whether changing the thread priority resolves these.

Quote

"Background" tasks, will also change how much process time in_mad has.

I assume that odyssey disabled all running tasks except Winamp itself (and the system processes, of course ) before running his tests. If he didn't this whole discussion would be nonsense anyway.

Updated in_mad Winamp MAD MP3 input plugin

Reply #186 – 2006-09-11 12:01:13

Since I'm currently at work I'm using another PC for my test now. No DSP's and both plugins set to priority "Normal". (Btw. I was unable to find a "null" plugin that would decode independent of timing in files)

For in_mp3 I measured around 3 sec decode of a 2:30 track. in_mad did this in 14 sec (still better than before, but I don't have one of the older versions here to compare).

I was unable to measure anything on this PC with the priority set to "Highest"; in_mp3 would decode faster than Winamp could react (possibly a combination of the high priority and my disk being the bottleneck), and in_mad would just make Winamp freeze until it was finished.

Junon: Are you sure you are switching between the plugins?

Quote from: Junon on 2006-09-11 11:54:05

I assume that odyssey disabled all running tasks except Winamp itself (and the system processes, of course ) before running his tests. If he didn't this whole discussion would be nonsense anyway.

This would be sufficient for small differences tests - When the difference is this big, the environment does not have a great impact.

Updated in_mad Winamp MAD MP3 input plugin

Reply #187 – 2006-09-11 12:35:50

Quote from: odyssey on 2006-09-11 12:01:13

Junon: Are you sure you are switching between the plugins?

Of course. Every time I restart Winamp after having enabled/disabled in_mad and having added/removed the MP3 extension to/from in_mp3 I view the file info to ensure that the correct plugin's currently active. The properties window created by MoSPDude looks quite unique compared to standard in_mp3's one.

Edit:

Quote from: odyssey on 2006-09-11 12:01:13

This would be sufficient for small differences tests - When the difference is this big, the environment does not have a great impact.

That might be true. However, it's hard to tell since I don't know which processes are exactly running on your machine while testing the plugin.

Updated in_mad Winamp MAD MP3 input plugin

Reply #188 – 2006-09-12 11:41:33

I'm currently working on an ID3v2.3 mode for libid3tag, at the moment it writes "hybrid" ID3v2.3 tags, that is ID3v2.3 tag and frame structure with ID3v2.4 frame types. I'm wondering if this is acceptable for a compatability mode or not?

I think I'm going to aim for it to leave both types of frames in (for example both the ID3v2.3 TYER and upgraded ID3v2.4 TDRC) and decide what to write when it comes to update the file tag depending on desired written version. Either this, or override libid3tag updating behaviour - keeping ID3v2.3 frames as ID3v2.3 frames, and ID3v2.4 frames and ID3v2.4 frames. All ID3v2.2 and less tags, will still be upgraded to ID3v2.4 type regardless of what happens.

Opinions on the above are very welcome

I might even fix the CRC problem I've been having with ID3v2.4 tags while I'm working on libid3tag.

Updated in_mad Winamp MAD MP3 input plugin

Reply #189 – 2006-09-12 16:34:57

Why has in_mad begun to stumple every time you seek?

Updated in_mad Winamp MAD MP3 input plugin

Reply #190 – 2006-09-13 17:47:51

I don't know why it stumbles, and I can't reproduce it, I have been making some more tweaks to improve seeking, so maybe that will clear it. Does it do it on all files, or certain types of mp3? For the moment, I'm working on the libid3tag library.

If anyone has any problems like this, if your output plug-in has a status window, then you can view both the output plug-in status and in_mad buffer status - and see what happens eg any buffer under-runs etc.
I do this with the DirectSound output when I'm testing buffer behaviour as both together give a good indication of the input->output plug-in connection.

Updated in_mad Winamp MAD MP3 input plugin

Reply #191 – 2006-09-14 16:19:41

I've uploaded another update, download from the usual location.

This includes working ID3v2.3 tag support (hopefully solving TYER issues), changes to the Advanced/Basic editor switching, changes to seeking (I think this did fix odyssey skipping problem when I checked against last version) and a few other minor things. I had also updated the EQ FFT routines used by shibatch supereq to the last version available.

A quick note on the ID3v2.3 tag support,
no writing, no conversion prevent - all tags will be written as updated ID3v2.4
writing, no conversion prevent - all tags will be written ID3v2.3 (with no change to frames!)
no writing, conversion prevent - all tags will be written ID3v2.4 (with no change to frames!)
writing, conversion prevent - tags will remain the same version

Thanks for all comments in advance.

Updated in_mad Winamp MAD MP3 input plugin

Reply #192 – 2006-09-17 13:04:47

I've uploaded another minor update.

This addresses some VBRI issues (although I've not fully tested as I only have 1 file with a VBRI header!) and some work towards a multi-lingual version.

If anyone has found any more issues or bugs, please post and I'll look into it.

Updated in_mad Winamp MAD MP3 input plugin

Reply #193 – 2006-09-17 21:31:43

For a start sorry for my English...
Thank you for updated plugin.
But can you fix one bag?
Example:
When I want to display in playlist TAG (for example) "Encoder" I write in options of plugin %#TENC
and all good, but only if file have in field "Encoder" something... If file have not this field winamp crash...
If | Else don't help.

Updated in_mad Winamp MAD MP3 input plugin

Reply #194 – 2006-09-17 21:53:48

Obviously the plugin only supports displaying the kinds of tags shown when clicking the "Help" button in the Title/Tags tab. I've played around with a few alternative entries, including yours, only to see all of them crashing the player, no matter if the required field was present or not.

But anyway, even in case this was fixed, your example still only worked correctly using files tagged with ID3v2. You'd have to define a whole mass of IF|ELSE conditionals for the player to be able to also read the tags of files which contain nothing but ID3v1 or ID3v1 and APEv2. Might become a bit complicated - at least for me it was a bit troublesome to find out how to define my current "%?1<%1 - >%?3<%3 - >%?0<%0 - >%?2<%2|%8>" setup. But maybe I was just slow on the uptake.

Edit: Modified my answer a bit because I misunderstood the question.

Updated in_mad Winamp MAD MP3 input plugin

Reply #195 – 2006-09-18 11:48:56

I've fixed the above ready for the next update, I'm just finishing some work on moving all fixed strings to the resource file.

If the plug-in can't find a field it places a '?' - to tell you its not there. You can use '%?#XXXX<%#XXXX>' to override this. I have been thinking of extending this to accept a similar syntax to Winamp 5 advanced title formatting.

Updated in_mad Winamp MAD MP3 input plugin

Reply #196 – 2006-09-18 14:27:35

One more request to you.
It will be very good for me if on the "File info..."(Alt+3) dialog in field ID3v2 in Basic mode will be a button "Copy from ID3v1 Tag"...
I know that this button is in the advanced mode, but...
By the way, when I copy ID3v1 tag to ID3v2, and tag fields not in English, ID3v2 display not readable symbols(but ID3v1 tag display good).
Hm... I see that always when file have ID3v2 tag not in English it display not readable symbols but always ID3v1 tag display good!?
Can you fix this?
Thank you once more!

Updated in_mad Winamp MAD MP3 input plugin

Reply #197 – 2006-09-19 12:33:40

Very nice plugin im loving it

Any chance you can fix shoutcast title support from this stream:

http://stream.mmradio.dk:8000/listen.pls

It works fine using standard in_mp3.dll and it also plays if i disable title support in in_mad.dll but i wouldt really like the title to work in in_mad.dll to

Thanks for a greate plugin
Domin

Updated in_mad Winamp MAD MP3 input plugin

Reply #198 – 2006-09-19 17:10:04

I don't see any mention of this so I assume it hasn't been fixed (I have the version from last week sometime). Buffer errors on seeking! ..which then cause sync errors. Older versions did not suffer from this.

The issue with the ZOBS year no longer occurs (neither of the 2 new options are checked). It is now safe to switch between basic and advanced mode

RG for non-RG'd lame encodes now seems to work properly, using the preamp for no-RG as it should.

Keep this good stuff coming

Updated in_mad Winamp MAD MP3 input plugin

Reply #199 – 2006-09-22 17:32:46

I'm preparing a new update, this should play more internet streams with shoutcast titles happily now.

The buffer errors on seeking shouldn't cause any audible problems, they're caused by the new seeking and shouldn't really be counted as errors - though sync errors shouldn't occur at all as the stream is resync'd before further decoding. I've made some more changes so hopefully that'll clear it up.

The ID3v1 to v2 character problems are in libid3tag, I'll make it use the Windows conversion routines. The basic mode copy from ID3v1 button will be added as well.

I'll post again once I've uploaded it. Has anyone found any other bugs I might get to look at before I upload an update?

Thanks to all

Notice