oh goddamn..... russian letters are not seen in both id3v2 tag editor and media library, i see dots instead of letters

The plugin has no international support at the moment, but it is on the to-do list. At the moment the EQ editor is taking a lot of work. I've also made some changes to the decoding loop in an attempt to improve buffering.

I have finally uploaded a new update to the usual location!

The EQ on this update is now completely functional, with the 32 bit support, and EQU2 tag reading and writing. The EQ editor still needs a little more work, but I thought I'd put this up for those that are testing the plugin. At the moment, it writes one EQU2 tag with a maximum of 128 points to be applied to both channels. The ability to write a separate EQ for each channel is possible, I just need to finish it.

Probably the easiest way to apply a curve, is to link with the Winamp EQ (in configuration), create your setting, then save the active EQ data to some files, and when finished - remove the link with the Winamp EQ.

I've made some more minor changes, the most significant would be the buffer->decode loop no longer waiting around unnecessarily.

I'm going to make some more changes to the EQ editor, and as always your comments and suggestions are welcome.

Thanks

Well i download your new update, but it hangs my pc, winamp takes 99% of cpu in task manager. All older updates have worked well.

hellgate, does it lock on loading Winamp, or on trying to play a file? In either case, try entering the registry and deleting "HKEY_CURRENT_USER\Software\Winamp\MAD Plug-in" to reset the plugins defaults, and also disable any DSP plugin you might use. What output plugin are you using as well?

Thanks in advance

I have just noticed that its causing things to take a long long time accessing files......

OK, I've uploaded another update to the usual place.

I've added a sleep in, as the decode loop thread was hogging processor time.
@hellgate, does this update fix your problem?

This is SO cool. I only see one possible problem with this in the future: When lowering mid-bands the overall gain will be lower than a calculated replaygain value. But if the thought was to make a more interative EQ, a slider for gain-tag could proberbly be implemented?

Edit: Well actually now I only need a preset function to remember used EQ's

Another edit: Okay it's actually quite a hassle to edit EQ without ability to hear the real results (Or maybe i'm just not best friends with Winamp EQ!)

If you enable the Winamp EQ link, and turn the Winamp EQ on, then check the store active EQ box - as you edit the Winamp EQ you should be able to hear the changes (after a buffer time lag) and these will be stored to the file when you save. You have to remember to change/disable the Winamp EQ after otherwise it'll apply them twice (the file EQ, then the Winamp EQ).

Was thinking of making the EQ display larger and/or easier to use - so can click to create a point for adding to the EQ, along with a Preview option.

In your Init() function, set mod->UsesOutputPlug |= 2 to disable Winamp's EQ (or any time, just be aware that winamp clears all but the first bit when it forst gets your In_Module from winampGetInModule2)

I've already included that, along with module.UsesOutputPlug |= 8 to disable the upcoming RG support I had read about on the Winamp forum. The double EQ is applied by in_mad as it takes both the file and the Winamp EQ specified settings.

@benski, Talking of this international support, how do I go about it with the Winamp DLL interfaces? I thought Unicode, but I think I read on the winamp forum that winampGetExtendedFileInfoW etc. was unsupported and not really to be used. Any pointers would be of great help!

You can implement winampGetExtendedFileInfoW in addition to the existing winampGetExtendedFileInfo. It is supported from 5.22 onward, but is safe to declare even with old Winamp versions.

Declaration:


Implementing the rest of the unicode plugin stuff isn't absolutely necessary, Winamp does a decent job of giving you a "fake" filename if the real filename has foreign characters. Especially since the majority of in_mad users are probably using older Winamp versions.

Ah right, thanks! Your probably right about everyone using older Winamp versions. I'll get round to adding it eventually. Cheers benski!

you broke it

New one is CPU hungry. 100% during playback. (maybe do to the quicker playback thing?)

Why is the 'buffer' tab present when a file isn't playing? Not present in previous version. (found out the hard way when clicking on it froze my whole system )

I'll stick with the previous version till those problems are fixed. Good luck

I'm very interested in these CPU hogging problems, though I'd have thought the previous Sleep would have solved it, with the difference that it decodes some audio data in between.

I've uploaded another update, with the Sleep moved to a better position. If this fails to work, it looks like its back to the old way or maybe include an 'experimental' option to allow data to be decoded while waiting for the output plugin to make space.

@gameplaya15143 and hellgate, what CPU type and speed are you running?

EDIT: I've also fixed the buffer tab problem, bit of a copy n paste error when I added the EQ tab! sorry about that!

lol, it happens

The cpu issue is gone

Running a P4 2.4GHz by the way.

I think I've figured where the CPU hogging came from, the last update should be OK for all. Under certain circumstances, there would be no situation where the output buffer was full, and the output plugin wasn't wanting data, causing it to forever decode and output, running the thread at full power.

I'm currently trying to add more functionality to the EQ editor.

Cheers for all help!

Thank You, best "customer service" in world . Ur new update works

I've uploaded a new update.

This now allows both left and right EQ to be defined and saved to a file. I've included a preview mode, so you can hear changes as they are made. You can also now add a point by double clicking the EQ window. Basic tooltips can also be found in the configuration dialog box.

I'm getting about ready to ask people to make some langauge translations.

Keep your comments and bug finding coming, and as always thanks for everyones help.

I doubt this has changed in the latest update...

Replay gain problem:
Lame encoded mp3s that don't store RG data should use the preamp for files with no RG. It is not doing that. Instead it pretends that the RG is 0dB. This happens with older versions of lame (which don't calculate track gain) and with newer ones as well when RG calculation is disabled.

Lame tag problem:
Doesn't seem to read the lame tag for 24khz samplerates and below (at least I can't view the tag info). Shows xing tag as being present (which is correct as it is there), but does not report the lame tag.

There was something else too.. but I can't seem to remember it
Oh.. just remembered.

VBR seeking:
It's not accurate in_mpg123 is. It's not a big deal, just a bit of an annoyance

About the advanced tagger... I was kind of hoping for a button right on the ID3v2 and ape tag tabs to 'go to advanced mode'. It's a little bit of a pain to switch between the two as it is. Problem is, there doesn't seem to be enough room for a 'go advanced' button on either tab. Something to think about.

MoSPDude, good work with the plugin. It is very informative and seems to work well in general.

Yet, i would like to point out that the way you're doing buffering is probably not the best one.

I've got a 6M down/512Kbit up ADSL line, with relatively low ping times and was getting skips on some streams until i decided to change some settings, (i also have a low audio buffer ( 200ms ))

I changed the "Input" buffer to 24KB ( 16 was also good ), while leaving the Output at 128KB ( I used to have 96KB with in_mp3 anyway ), and that solved the problem.

Yet, with this setup, i still wasn't getting the results i was expecting... the network activity still showed chunks of data being downloaded non-constantly ( say.. 30KB/s during two seconds, then 0KB next second, or a peak of 60Kb/s and then two seconds of 0KB/s).

So what are you doing for buffering? I would say a good way to do so would be

1) keep connection open (i assume you do so, but just in case)
2) download in chunks of "Input buffer" size until you've filled the output buffer.
3) when the output buffer has played at least a size as big as "input buffer", try to fill the input buffer again, and keep until output buffer is full again.

Good defaults for these would depend on stream line, of course, but Input buffer has to be clearly smaller than the output buffer.

You might want to check the network usage with the in_mp3 plugin. you'll see that the download rate keeps much around the stream bitrate, while with in_mad, it's always peaks and valleys. (check with the task manager)

Also, not sure if it will keep happening, but right now, playing this link hangs in_mad (no CPU usage, just hung): http://www.m1live.com/listen/musicone_hi.pls

@[JAZ], OK, I've just tried http://www.m1live.com/listen/musicone_hi.pls and in_mp3 can't connect to it either. At the moment in_mad is missing connection timeouts etc and this is why it hangs.

The buffering does need to be re-written - its been inherited from the MAD 0.14.1b plug-in. Its all included in the decoding thread loop. Basically, it does what you suggest anyway, but where and when the decoding occurs is an issue. Basically, 3 main things need to happen and they can't be done simultaneously, that is fill input buffer, decode, and maintain a full output buffer. The current decode loop goes basically like this,
1. Enter input section.
2. If file, read in to fill input buffer. If stream, read in 'metaint' bytes, process shoutcast metadata if needed, output some audio, loop to fill input buffer.
3. Enter decoding section.
4. Check if able to decode a single frame, if not enough data in input buffer goto step 1 or other problem then handle it or abort.
5. Decode a single frame.
6. Output audio data if output buffer full, until one frame has been sent or output plugin signals its full.
7. If not told to stop, loop to 4

One of the previous major problems with streaming was that when it was trying to get data from the stream, as no audio data was being sent, the output plugin would buffer underrun. This was helped by placing audio output with the data reading, though the main reason for a larger output buffer initially was gapless output (on detect of EOF, it hacks off the end of the buffer accordingly for gapless).

The reason for it downloading a chunk suddenly, then none for a while, is the process of input section downloading to fill input buffer, then the decoding and output section afterwards decoding it.

I could try to make it download continuously to re-fill the input buffer on every loop, but for file usage when I made it decode and output continuously, some people reported 99-100% CPU usage as was non-stop decoding and outputing a single audio frame. Streaming, decoding and outputing continuously might do the same thing.

I'll get round to having a proper look at it eventually.

@gameplaya15143, The LAME tag RG problem is partially to do with lame, it always marks the file as having that information - even though it hasn't (well its set to 0dB). I can make it ignore it if its 0dB, but some files could really have RG set with 0dB. I'll have a look into the LAME tag less that 24kHz samplerate issue. VBR seeking needs to be implemented, it ignores the tables in the XING tag (and the VBRI tag too).

I've been thinking of making the dialog boxes bigger, then can have more room to do the EQ editor.

Will hopefully get another update done soon addressing some of the above.

I've made that change I thought of while writing the above, and it seems ok on my system. Internet streaming is now continuous in small blocks. I'll upload it later, for people to test and see if it bring 99% CPU issues back.

I've uploaded another update to the usual location.

This has continuous internet streaming, internet connection timeouts, it ignores LAME replaygain if set to 0dB, has XING VBR seeking using table implemented, and now shows LAME tag when used with MPEG-2 encoded files (24khz rate and less).

Thanks for all bug reports and suggestions. I'm going to resize the dialogs to allow for a "Basic to advanced button" at gameplaya15143 request, and add more touches to the EQ editor.

I've uploaded another minor update.

This has the Basic <-> Advanced editor mode buttons, and now runs the id3v2 text fields through the Windows code page conversion to ANSI strings. I'm interested if this will allow more foreign characters to be displayed that the libid3tag straight conversion does (obviously depending on the users ANSI code page settings).

i wonder, what's the problem is it : i see dots instead of names of SOME russian song(mp3) in winamp's ML and PL, but all of them are god with tag editor. also i see russian words in other songs in ML but i see abracadabras in id3v2 and normal names in id3v1,.... i may send you problem files, but you cant see russian symbols i think

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.

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.

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.

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!!

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.

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.



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



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...

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.

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.

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!

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.



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+.

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.

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.



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.

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?


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

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:


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.

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.

Why has in_mad begun to stumple every time you seek?

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.

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.

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.

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.

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.

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.

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!

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

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

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