I have been working on speed enhancements for WavPack and think I have made enough progress to justify a release. The improvement seems to vary quite a bit on different systems, but I couldn't find a system where this didn't make some improvement (even a few percent) and on some systems (like my old 1.7 GHz P4) it is significant. The improvements apply to both packing and unpacking stereo files. Note that this is still pure C; there is no hand-coded assembler.

This also includes the MMX code (via intrinsics) from Joachim Henke. Unfortunately, this only seems to provide an improvement for bitdepths over 16, so it's restricted to that for now (although it does make a nice improvement for 24-bit or IEEE float data). Regarding MMX support, is that ubiquitous enough now that programs simply use it without checking for it? Since WavPack now requires Windows 98, it is reasonable to assume that any computer running Windows 98 also has MMX?

A bug has been fixed that sometimes caused a crash if a metadata source file specified on the command-line was not found, but otherwise this release only involves optimization. The output files should always be bit-identical to 4.40 regardless of the mode. This code hasn't been checked in to SVN and I haven't tested it on Linux, but that will come shortly.

Many thanks to the WavPack users and also thanks in advance for any comparison testing done on this new version, which can be found here.

David

Well, AFAIK, you can run Windows 98 on a 486DX without MMX, but I doubt anyone is doing that. Here's a list of CPUs that support MMX (German, but you should easily get the point):

http://de.wikipedia.org/wiki/MMX#CPUs_mit_MMX

Thank you very much for this new beta release, David Your work is very much appreciated

I sometimes have some periods where i totally change my mind about something and this happened a little while ago, where i changed from WavPack to FLAC. Now their has gone about 14 days and now i'm beginning to come back to my old way of thinking again, and so i again changed my mind back and am now in the process of transcoding my FLAC images back to WavPack

Again, many thank's for your great work David and i humbly apologise for my last 14 days of "un-loyalty" to the great WavPack format, and i hope that you will forgive me from changing "sides" momentarily and to let me pass into the WavPack community again

CU, Martin.

Hi Martin!

I actually almost thanked all the faithful WavPack users in my original post as a subtle reference to your very visible defection, but my good judgement prevailed. Glad you're back!

After what sometimes seems like daily announcements for FLAC support in various software and hardware, it doesn't surprise me that WavPack's popularity has slipped over time (at least with HA members). I have done everything I possibly can to make incorporating WavPack support in a product painless, but I suspect that if a vendor has to choose a single (or first) format to support then FLAC is the obvious choice simply because it already has the widest support. My hope is that some WavPack fan in the right position will steer a decision my way, or I will get a job with a company making audio devices and do the same (I interviewed at a well-known music server maker, but never got a call back... ).

In any event, WavPack can continue to provide a viable alternative, especially in applications where one of its features helps fill a niche (like the hybrid/lossy mode, float support, RIFF chunks, integer-based encoding, etc.), and can also provide Josh with incentive to continue pushing the envelope with FLAC.

That is, of course, until everyone switches to Tak!




Thanks for the info. I guess I'll not worry about it for now except maybe a notice somewhere that audio resolutions greater than 16-bit require an MMX-capable CPU.

You sound like being a bit sad because of hardware support which is bigger for FLAC.

Hope you're not really dissappointed. You do such a great work.
And may be when lossless encoding becomes more widespread than now also top quality lossy encoding becomes more widespread cause it saves some 50% of file size or more compared to lossless while keeping extremely good quality.

As for lossy/hybrid mode wavPack has the best hardware suppport. When we'll have 16 or 32 GB flash players (expected to arrive soon) with rockbox support (hopefully) or maybe even natively (even better), wavPack lossy will be one of the most adequate fomats to many people.

Keep up the good work !

I'm not sure Martin. I'm not sure that I want to hang around with a "FLAC user". As long as you can promise that you have kicked the habit completely, and will not "use" again then perhaps we can begin your rehabilitation one step at a time...

Hey, who am I kidding: you're a very useful person to have onside. Welcome back brother!

I'm a bit gutted actually. I've been running tests all day, on various settings using both 4.40 and 4.41, and the testing had about 10-15 minutes to go and I had to shut down the PC so that we could put my son to bed. Wife's orders.

Looks like I will have to finish the decoding tomorrow (20:00pm here) and post then - around 15 hours' time. Shame, as I was really looking forward to seeing the figures

Anyways, thanks for the update David.

Just wanted to add my 2 cents. I've been using WavPack for quite some time now. I admit I still use FLAC, but WavPack is my favorite. I find it particularly good for my own music, since my masters are 32-bit audio. I'm not sure if FLAC even supports that bit depth. but 32/96 and 32/48 audio takes up some space, and WavPack compresses these files quite nicely (-hhxm). One thing I would like to see is support for WavPack in the Squeezebox, at least in the software. I wouldn't worry about hardware support too much, I really don't think that many people put lossless audio on portable players. Might be something to make a poll for. So keep up the development. Been doing a great job so far. Fact is WavPack was basically unknown a few years ago and now seems to be in the top 3.

Thank you very much David, i really appreciate it Btw, i also changed to using only GNU/Linux(Debian) instead of win32, besides changing to FLAC, but now i'm back for good with WavPack and on win32

Thank's again, my friend

CU, Martin.


ROFLMAO You are hillarious, Synthetic Soul

Thank you very much for the kind words, my friend

CU, Martin.

sweet. changes are now in SVN . now if only Visual C++ didn't crash everytime i started compiling

Why not use the provided binary?

right now, that's what i'm using(although i havent' encoded any songs yet). but for some reason, if i compile my own versions, then i get a faster binary which is faster by 10 seconds. it's not much, but i guess it's worth it.

i personally want to use MinGW to compile it and compare differences between VC++ and GCC since VC++ usually makes bloated exes.

I too am interested to see what happens on other systems. This optimization business can be kind of a circus with all the different CPUs and compilers and their switches. Sometimes I'd come up with an improvement and it would be 20% faster on my primary system, then I'd try it at work and it would be much slower! What I finally came up with was faster on all three systems I tried, so my fingers are crossed...

I just built it on gcc for Linux and most of the improvements seem to work there as well, especially when I tell gcc to optimize for my exact CPU (a feature which Microsoft seems to have decided was more trouble than it was worth and deleted from VC8).

Anyway, Neil, thanks for giving it a go and thanks to everyone for the kind words and support!

Now my wife is trying to put me to bed, so I'm going to have to wait also...

David

OK, finally, here they are:


There is definate improvement, most noticeable when encoding when the x switches are not used, and more prominent with the faster settings.

All 16 bit files I'm afraid, so no test for the MMX code.


NB: Given that 144 people so far have stated that WavPack is their codec of choice in the 2007 poll, it would be nice if more than three people provided some data.

C'mon kiddies: time to show the nice man your appreciation...

Hi Bryant,

A quick note to add my thanks for your efforts.

I've been using it for a couple of years now and, coming from an audio (rather than software) background, WavPack has been one of the things that made me a convert to PC-based audio.

Best

Midas

You are right Synthetic Soul.
I was using FLAC/REACT to backup my collection, then I had a HD crash (after about 100 CDs).
Anyhow, after I got the computer back and running, I seriously looked at WV versus FLAC. I made the switch to wavpack images to backup my collection. I love it.
I also tried 3 CD rips using REACT/wavpack beta, and it works great. I don't have the numbers to back up my claim, but the speed increase is great.
Thank you for such a great program.
And if there is any concern, it works great on Vista.

Thanks for the test! It's interesting that the improvement was so modest, but it's comforting to see that none of the settings seemed to get slower.

On my older system the decoding improvement was about 15% across all modes and the encoding improvement was as much as 30% in the higher modes. Hopefully some other results will show more significance; I can't imagine this alone being worth its own release (although it's obviously worth keeping).

Easier said than done.

Ok, I fetched your comparison-scripts-v1.2 (hope it's the latest version) pack and modified it for comparing 4.40 against 4.41...
that's two times 16 folders. What's the maximum disc requirement I can expect to be used? I hope the test en-/decodes will be deleted right after the processing so I won't end up with 8-16 times the size of the source folder, right?

Does it calculate the average times or do I have to do that myself (I think I've seen the word "spreadsheet" mentioned in the lossless comparison thread... I guess I could get that to work with OpenOffice Calc).

Another question: Can I skip the md5 part? I don't think it's necessary and will only make the test longer (and more likely that I will cancel it).

Currently fb2k is still decoding the originals.

Hi David,

I will be happy, if TAK will find it's niche, at least big enough to justify all the work put into it's release... But thank you very much for the encouragement!

BTW: For me WavPack is a great codec! Especially for it's simplicity. Please don't take me wrong, i want to say in my bad english: simple + efficient = ingenious! With simple i mean the code complexity, not your great altgorithm. I would be glad, if TAK was equally compact, but no chance.

I also like your simple to use code interfaces. I hope you don't mind, that i used them as a model for my new SDK...

I want to say thank you for your great work and i really hope, you will continue it. But please don't improve it too soon too much, please give TAK some time... Honestly i am always most curious if a new Wavpack version is beeing released, because regarding efficiency, WavPack is TAK's real (friendly) competitor.

Let's work on further improvements and have some more fun!

Thomas

I seem to remember that my corpus didn't fair so well with your improvements last time. I was kinda hoping someone else would post some results before mine to balance it out a bit! Anyway, considering that they are pure C amendments, and as you say none have worsened, it's most certainly better than a poke in the eye with a sharp stick. To try to make it sound slightly better: with the default encoding I shaved 15 seconds off a 202 second encode phase. I don't think that's all that bad.

True. I'm glad that you have made an effort though. David deserves some help from us.

MB used depends on the size of your corpus. If you run encodeall.bat and then decodeall.bat you will need room for the source, all encodes, and one decode set (1*wav + n*wv + 1*wav) before you start removing files with the decode scripts. If this is a concern write a short batch file to call a folder's encode.bat and decode.bat in turn - then you only need room for your corpus and one encode/decode set (1*wav + 1*wv + 1*wav).

You have to collate the figures yourself. I used Excel for the report above. It's a simple/boring copy'n'paste job...

Remove:


... from all decode.bat files.

BTW: All 1600 encodes (50 files encoded using 16 settings for 2 versions) matched for me.

NB: I have uploaded my spreadsheet and all script files (including the resulting txt files) here.

Well, obviously I appreciate the incredible amount of work that Synthetic Soul has put into his tests and precedures. However, it is also possible to provide useful information on different systems with virtually no work. For example, here are results from my system using just a single track. I always do a couple test runs (not shown) to make sure the sources are in disk cache and I either write the output to "nul" for encoding or just use verify mode for decoding to make sure that no disk I/O is entering the timing. I get results like this:

Decoding test (sorry, you have to scroll a little to see the differences):
Encoding test:

Finally, when I want to verify that I haven't broken anything I just pipe the output to md5:


Hopefully someone will get results somewhat like mine, otherwise I spent all that time optimizing for a single computer!

Yeah, the fast and normal modes show a nice improvement. I also saw less improvement on the 2 newer systems that I tried (although still more than you) so I suspect that somehow the newer CPU is simply able to more efficiently handle the things I am optimizing out.

BTW, how do these results compare to other results that you have for other codecs? The numbers don't seem to jive with the public version of your corpus that's here so I suspect the procedure (or system) is different now.

Thanks! It's interesting that one of my goals for WavPack 4.0 was to make it as simple as possible. So, I worked hard on figuring out decorrelation and entropy encoding methods that would work well with both lossless and hybrid modes and work well with both fast and slow modes, and was very happy with the final result.

Of course, now, when I want to speed things up, I realize that some of the compromises I made for simplicity now are costing in efficiency. I could create a new mode specifically for lossless that would achieve the same compression at greater speed (and be more MMX'able) but that's what I was trying to get away from.

Of course I don't mind; I'm glad you found something useful there!

Don't worry, I don't think there's anything coming soon. I think the only way to make a significant improvement in WavPack's speed would be to start rewriting several large functions is pure assembler. Now, I would really like to do that, but unfortunately I just can't justify the time required.

BTW, I haven't been following all the TAK discussion closely enough to know whether you are using any hand-coded assmebler in there. I remember at one point you said that it was pure Delphi, but I was wondering if that was still the case (I know you must at least be using some intrinsics for MMX). And if not, do you think you'll be able to get further speed gains if you ever tried that?

Absolutely!

BTW, if you'd like to send me your code I would be happy to look it over and let you know what I think. I bet Josh would even help me and I'm sure we could come up with some good ideas for you!

Very brief test on a P3-550MMX:

normal mode +6 % improvement

high + 8.7 %

v-high: + 10 %

fast: + 7 %

normal x1: + 15 %

normal x3: + 18 %

v-high x3: + 20 %


Good work David !

Thanks for letting me know. I'm glad that someone's getting results along these lines!

The results posted here are for CPU-only (my preferred format), while the comparison on my site reports CPU+IO (that's how it started, so for now, unfortunately, it must continue that way).

All the results on my site were produced with 512MB of RAM in the machine. I recently got given 1GB so I could upgrade. I am concerned about mixing results from both set-ups. I'm a bit dim when it comes to such things: would the additional RAM change results?

I did some testing for FLAC 1.1.4 recently. I re-did the 1.1.3 tests and compared the 512MB test and the 1GB test and the figures appeared to be very similar. My intention was to compare the 512MB and 1GB 4.40 results also.

Anyway, for now there are my FLAC 1.1.4 results, but I'll try to make a correlation with the others if I can.

Ah, this is perfect! I just wanted to compare the results to something else, and that will do fine.

Assuming you aren't running anything else on your PC during the tests I wouldn't believe that adding memory would make a difference (assuming it's the same speed memory). Certainly none of these programs are going to approach using even 100 megs, right? It would mean that there would be more disk cache available, but I wouldn't think that would make a difference either because you're not processing the same files over and over again. But I'm certainly no expert...

I checked the CPU-only results of both 4.40 runs (512MB and 1GB RAM) and they were suitably similar.

However, after adding the results for WavPack 4.41 and FLAC 1.1.4 to my CPU+IO comparison table I have seen that the 4.40 times are better than the 4.41!! Given the the CPU-only times reported I can only assume that this is down to my system - perhaps down to the disk cache that you mentioned? Anyway, in conclusion, the new CPU+IO results are worthless, until I can get the whole table up to tests run on my 1GB system.

I will try to run some tests on my laptop (AMD Turion 64 Mobile ML-36) to get you some more data.

It occurred to me that it might be worth looking into the following items in order to make the CPU-only tests more precise and/or the CPU+IO tests more repeatable:

1. A high performance ramdisk driver for windows.
2. A high performance /dev/null equivalent for windows, if such a thing exists.
3. A means of preloading the system cache with your input file.
4. A means of ensuring the system cache does not have your input file preloaded at all.

Just throwing out some ideas...

-brendan

With a Pentium 4 2.6GHz speed increased like this:

(based on process time according to timer.exe)

Wow, the improvements reported by shadowking and gaekwad2 are far more impressive! Superb.

Also, curious that mine was more apparent in the faster modes but theirs in the slower. Both their machines are Pentiums, while mine is an Athlon XP +2400. Unfortunately my laptop is an Athlon also. Had you seen results from an Athlon previously? Is it possible that compiler switches are somehow geared toward Intel chips?

Edit: I know it's a little early to be making conclusions, but hey.. I'm bored!

Edit: Bit late, but had to amend that hideous "there's"/"theirs" error...

Sorry if this question is stupid, but I didn't follow discussion about testing the speed - is there a special test suite available for download somewhare or do I have to feed the encoders with my own files?

Please forgive me for first testing the new beta now, and because of little time, then i have only tested one image consisting of 11 tracks(Evanescence - Fallen) and i have only used the -h switch.

For the test, then i used an Intel Celeron 1.7GHz with 256MB RAM(the Celeron 1.7GHz is identical to a P4 Willamete(first P4 generation), except with only a half L2 cache size).

(wavpack = v4.40)

timer wavpack -h test.wav > log.txt

Timer 3.01 Copyright © 2002-2003 Igor Pavlov 2003-07-10

Kernel Time = 6.699 = 00:00:06.699 = 5%
User Time = 101.525 = 00:01:41.525 = 83%
Process Time = 108.225 = 00:01:48.225 = 89%
Global Time = 121.204 = 00:02:01.204 = 100%

timer wavpack441b -h test.wav >>log.txt

Timer 3.01 Copyright © 2002-2003 Igor Pavlov 2003-07-10

Kernel Time = 6.839 = 00:00:06.839 = 5%
User Time = 91.351 = 00:01:31.351 = 75%
Process Time = 98.191 = 00:01:38.191 = 81%
Global Time = 120.473 = 00:02:00.473 = 100%

timer wvunpack test.wv >>log.txt

Timer 3.01 Copyright © 2002-2003 Igor Pavlov 2003-07-10

Kernel Time = 6.649 = 00:00:06.649 = 7%
User Time = 65.624 = 00:01:05.624 = 74%
Process Time = 72.273 = 00:01:12.273 = 81%
Global Time = 88.587 = 00:01:28.587 = 100%

timer wvunpack441b test.wv >>log.txt

Timer 3.01 Copyright © 2002-2003 Igor Pavlov 2003-07-10

Kernel Time = 6.919 = 00:00:06.919 = 8%
User Time = 55.289 = 00:00:55.289 = 70%
Process Time = 62.209 = 00:01:02.209 = 79%
Global Time = 78.383 = 00:01:18.383 = 100%


As always, very nice job, David

CU, Martin.

I've found in the past WavPack had some strange behaviour from this point of view. I used to repeat my test on a PIV, a PIII and a Sempron. When compared to other encoders, WavPack usually showed bad behaviour on the PIII. I think I still should have some tables around...

Anyway, here's some results on an Athlon64 3500+:



While on the decoding side the improvements are not as dramatic as they are on the tests on the Intel chips above, nevertheless the encoding speed improvements seems very good also on this AMD chip test.

My diminutive test says improvement is tangible !

That's also my experience: Highly optimized code and a good neat design don't go together...


TAK contains highly optimized MMX-assembler code. I wrote it in 1997 when i got my first Pentium 200 MMX. Without the speedup achieved from the MMX-code, my tests and evaluations would have lasted intolerably long...

But there is also a switch to disable the MMX-optimizations. Presets Turbo and Fast are performing quite well without MMX (about 40 percent less encoding speed on my P3), but the stronger presets with higher predictor orders are getting much slower without MMX.

Unfortunately the MMX-usage also makes some transformations of the data neccessary, which probably are eating up the advantage for at least the turbo preset.

And for cpu dependency: My MMX-code is optimized for my P3 and should also work very well on the newer Intel cpus, which are quite similar to the P3. But the P4 is a strange beast (i never liked it...): My code is using many register moves and they are incredibly slow on a P4 (can be different for the latest revisions of the P4). A latency of 6 clock cycles for a simple Movq! A Pmaddwd doesn't take longer...


Thank you!

Thomas

It turns out that the faster modes vs. slower modes difference makes some sense. There are two components to WavPack (and other lossless audio for that matter) compression. The first is decorrelation where the redundancy in the audio samples is [almost] removed so you only have [ideally] noise of varying amplitude. Then the noise (sometimes called the residuals) is sent to the entropy encoder that turns it into a bitstream by [essentially] removing all the unneeded bits (because these numbers tend to be quite small).

The higher modes of WavPack are created by having the decorrelator make more passes over the data (2 for fast mode, 16 for very high mode). The entropy encoder (and some other stuff like JS and CRC) is always exactly the same no matter what the mode. So, in fast mode the entropy encoder (and other constant stuff) is most of the time, while in the higher modes more and more of the total time is in the decorrelator.

In this round of optimization I made improvements in both sections. But, if in your system for some reason only the constant stuff saw the improvement then the fast modes would see the big improvement, whereas in other systems the decorrelation improvements would help the higher modes more. Not a mystery at all!

My wife's laptop is also a Turion 64 and I saw improvement there also. Not as much as my P4, but more than your AMD. In any event, I am beginning to think the improvements are certainly worth it based on the other results. Yours are of course still greatly appreciated...



With some encoders it might make a difference, but WavPack should pretty much always run the same regardless of the source material. Use whatever you need to encode anyway...

I see. I imagine that the faster modes benefit less from MMX because more time is spent in the entropy coder (which I assume is not easily MMX-able, although I haven't thought about it too much).

Anyway, however you're doing it is certainly working incredibly well!


Yeah, I've heard other places that the P4 is an admitted Intel blunder (especially the early ones). Maybe it's not the best for me to be optimizing for! I also notice that mine seems to slow down significantly after just a minute or so of running WavPack, which makes benchmarking frustrating! Maybe I should make sure the fan is clean...

I hope you know that this was my poor attempt at a joke...

In next rough and absolutely not ultimate table, you can see a few random encoders performances on a PIV2.8HT, a Tualatin1.56ghz and a Sempron1.83ghz.
In the last columns you can see PIV to PIII performance comparison and PIV to Sempron performance comparison.
On the average row you can see the PIV being 41% (encoding) and 29% (decoding) faster than the PIII (on an average base) and 6% faster (encoding) and 1% slower (decoding) than the Sempron (on an average base).



Now, in next table you can see the same numbers on a few WavPack tests. As you can see the PIV is not less than 147% faster (encoding) and 50% faster (decoding) than the PIII (WavPack based), and 42% faster (encoding) and 14% faster (decoding) than the Sempron (WavPack based).

Again, those are not enough numbers to be considered ultimate, I only mean to show a possible behaviour.

When confirmed, this should mean that, in a comparison with other codecs, WavPack likes the PIV better than the Sempron and it likes the PIII much less than the other two chips. The PIV is encoding -hx3 over three times faster than the PIII and over 50% faster than the Sempron!

Finally, here's the results for my laptop (AMD Turion 64 Mobile ML-36):




NB: Different corpus to other test - no comparitive results (these are the first tests that I have run on my laptop).

Pleasing figures though.

Huch... ...... Ahh... .... I've got it!

This is very interesting, thanks for presenting it!

I guess there are just two possibilities. The first is that because I have done my optimization on a P4 (although a much older one than yours) the decisions have all been skewed towards that processor. The second is that something about the WavPack algorithm itself is more suited for a P4, like maybe the multiple passes over the samples. I don't know enough about the CPU differences to say, but I'd bet on the first guess.

It seems like the P3 decoding speed results are close to what I normally see in comparisons with WavPack "fast" just about matching FLAC. But the P4 results show the default WavPack mode matching FLAC and WavPack "fast" significantly faster than anything else!

Oh boy, more work to do...

Yes, I am perfectly happy with these results!

In fact, after looking over all the results I believe that this is certainly worth a release, especially considering that there doesn't seem to be regression anywhere.

Thanks again to everyone for their great help!

Yup no regression my side with hardcore punk, metal and ska so far (about 1500 files).

Silly question: any probs using your copytags.exe little proggy with this release too?

Thanks for your superb work, appreciated!

my short test



encoding times are aprox., decoding times not tested.
p.s. none of the encoders seems to use my two cpus.
p.s.2. sysinfo:
Property Value
Number of CPU(s) 2 Physical Processors / One Core / 2 Logical Processors
Vendor GenuineIntel
CPU Full Name Intel Xeon
CPU Name Intel® Xeon™ CPU 2.80GHz
CPU Code Name Prestonia
Technology 0.13µ
Platform Name Socket 603/604

Here's my quick test using the 'Finding Nemo' soundtrack on my P4 3GHz, 1MB RAM, XP Pro, default compression levels for all:


IMO, wavpack has very impressive performance on my system. Josh, if you want to see any other tests, just yell.

John

If it's of any interest I have now updated my online comparison.

As I had to redo all encoders (I dropped some, like LA, and MA Insane) I am now reporting CPU-only times, which I'm pleased about.

Append ?all=1 to view the 4.41b results

http://www.synthetic-soul.co.uk/comparison...index.asp?all=1

Thank you very much!

And fine that you are reporting CPU-only times!

Hopefully preset Turbo will be about 5 % faster in the next TAK version (No, this isn't the new dedicated Turbo codec...). This tiny improvement would hardly be noticeable with disk io times...

Thomas

Kudos to Synthetic Sould and both of you TBeck and bryant and the FLAC developers, too, of course.

This chart really shows very well how exciting the lossless codec developments are at the moment.

Thanks again for your work and results, and I also agree that CPU-only speeds make the most sense.

I just wish I could get a few more percent on the decoding speed to break 100x. The way it looks now it's easy for people to get WavPack mixed up with the riff-raff!

LOL @ riff-raff. Considering WavPack is the second favourite encoder on this board (according to the poll) I don't think you need to worry about that.

I don't really understand the MMX, SSE stuff; however would I be right in saying that, due to the integer arithmetic nature of WavPack, SSE code is pointless? Anything else up your sleeve?

-f is so close to 100x decoding speed with this beta. Although, of course, not too much credance should be given to my single comparison - these tests kinda hit that home to me.

Anyway, I'm sure all your users will agree, the extra benefit provided by this beta with no loss in compression is extremely welcome. Many thanks for your continued efforts.