Possible sector padding calculation bug in Imgburn

[fordman]

I've encountered an interesting occurence three times when using ImgBurn in the build mode.

 

I often use Imgburn 2.3.2.0 in build mode to write DVDs from the source files directly to DVD. I add the folder containing the VIDEO_TS and AUDIO_TS directories, and after setting a custom date and a label, I press the calculate icon which presents me with a choice of potential layer break positions. In the vast majority of the cases, the sector number (after padding) corresponding the the selecting layer break point matches that also shown when actually writing the DVD. In addition this number matches that calculated by PGCEdit, though the amount of padding needed to arrive at that sector is always two sectors diffrent between the two programs (I assume due to internal logic differences in the padding calculation).

 

In two instances I've found that the sector number calculated by ImgBurn's calculate function did not match that calculated during the write mode, though the write mode seems to be correct (it matches PGCEdit), so I'm confident that the DVD is being written correctly. In one instance, the calculate function actually advised me that there were NO potential layer break positions, but when I pressed the write button, Imgburn then found potential layer break points, which again matched PGCEdit, and I was able to write the DVD.

 

Is there a logic difference in how this sector is calculated in Imgburn's calculate versus write mode? I thought I'd post this in case there is a possible bug that needs squashing. I've posted the log of the most recent occurrence below (with debug mode on). Summary: calculate produces "Using Layer Break LBA: 2023891 -> 2029184" while write correctly produces "Using Layer Break LBA: 2023891 -> 2023904" for the same exact cell.

 

Any ideas?

 

fordman

 

----------------------- LOG Follows ---------------------------------------------------------------

 

I 19:35:05 ImgBurn Version 2.3.2.0 started!

I 19:35:05 Microsoft Windows XP Home Edition (5.1, Build 2600 : Service Pack 2)

I 19:35:05 Total Physical Memory: 2,096,600 KB - Available: 1,495,992 KB

W 19:35:05 Drive E:\ (FAT32) does not support single files > 4 GB in size.

I 19:35:05 Initialising SPTI...

I 19:35:05 Searching for SCSI / ATAPI devices...

I 19:35:05 Found 2 DVD-ROMs, 1 DVD±RW and 1 DVD±RW/RAM!

W 19:35:11 Program 'Debug Mode' has been Enabled!

I 19:35:19 Project Loaded Successfully!

I 19:35:44 Operation Started!

I 19:35:44 Building Image Tree...

I 19:35:45 Checking Directory Depth...

I 19:35:45 Calculating Totals...

I 19:35:45 Preparing Image...

D 19:35:45 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2144640

D 19:35:45 GenerateFileLBA_DVDVideo - MaxCapacity = 4173824

D 19:35:45 GenerateFileLBA_DVDVideo - MaxPadding = 200311

D 19:35:45 GenerateFileLBA_DVDVideo - Start/End LBA Match - File: VTS_01_4.VOB

D 19:35:45 Potential Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, Vob/Cell ID: 1/17, Time: 01:01:31, SPLIP Flag: Yes)

D 19:35:45 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP Flag: No)

D 19:35:45 Useless Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, VIDEO_TS Padding: 241001) - Reason: Cell requires too much padding.

D 19:35:45 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, VIDEO_TS Padding: 5293)

I 19:35:51 Using Layer Break LBA: 2023891 -> 2029184 (VTS_01, PGC: 1, Chapter: 17, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP: No)

I 19:35:51 Checking Path Length...

I 19:35:51 Image Size: 8,148,647,936 bytes

I 19:35:51 Image Sectors: 3,978,832

I 19:35:51 Operation Successfully Completed! - Duration: 00:00:06

I 19:36:15 Operation Started!

I 19:36:15 Building Image Tree...

I 19:36:16 Checking Directory Depth...

I 19:36:16 Calculating Totals...

I 19:36:16 Preparing Image...

D 19:36:16 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 1986768

D 19:36:16 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2086912

D 19:36:16 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2086912

D 19:36:16 GenerateFileLBA_DVDVideo - MaxCapacity = 4173824

D 19:36:16 GenerateFileLBA_DVDVideo - MaxPadding = 200311

D 19:36:16 GenerateFileLBA_DVDVideo - Start/End LBA Match - File: VTS_01_4.VOB

D 19:36:16 Potential Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, Vob/Cell ID: 1/17, Time: 01:01:31, SPLIP Flag: Yes)

D 19:36:16 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP Flag: No)

D 19:36:16 Useless Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, VIDEO_TS Padding: 241001) - Reason: Cell requires too much padding.

D 19:36:16 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, VIDEO_TS Padding: 13)

I 19:37:11 Using Layer Break LBA: 2023891 -> 2023904 (VTS_01, PGC: 1, Chapter: 17, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP: No)

I 19:37:11 Checking Path Length...

I 19:37:11 Image Size: 8,137,834,496 bytes

I 19:37:11 Image Sectors: 3,973,552

I 19:37:22 Operation Successfully Completed! - Duration: 00:01:06

I 19:37:22 Operation Started!

I 19:37:22 Source File: -==/\/[bUILD IMAGE]\/\==-

I 19:37:22 Source File Sectors: 3,973,552 (MODE1/2048)

I 19:37:22 Source File Size: 8,137,834,496 bytes

I 19:37:22 Source File Volume Identifier: DVD

I 19:37:22 Source File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!

I 19:37:22 Source File Implementation Identifier: ImgBurn

I 19:37:22 Source File File System(s): ISO9660, UDF (1.02)

I 19:37:22 Destination Device: [1:0:0] PIONEER DVD-RW DVR-111L 8.29 (H:) (ATA)

I 19:37:22 Destination Media Type: DVD+R DL (Disc ID: MKM-001-00) (Speeds: 2.4x, 4x, 6x, 8x)

I 19:37:22 Destination Media Sectors: 4,173,824

I 19:37:22 Write Mode: DVD

I 19:37:22 Write Type: DAO

I 19:37:22 Write Speed: 6x

I 19:37:22 Link Size: Auto

I 19:37:22 Test Mode: No

I 19:37:22 BURN-Proof: Enabled

I 19:37:22 Optimal L0 Data Zone Capacity: 2,023,904

I 19:37:22 Optimal L0 Data Zone Method: IFO Cell Boundary, 'SPLIP' Flag Not Set

D 19:37:41 Device Buffer Size: 1,605,632 bytes.

D 19:37:41 Device Buffer Available: 1,605,632 bytes.

I 19:37:41 Filling Buffer... (256 MB)

I 19:37:49 Writing LeadIn...

I 19:38:00 Writing Image... (LBA: 0 - 3973551)

I 19:38:00 Writing Layer 0... (LBA: 0 - 2023903)

I 19:46:37 Writing Layer 1... (LBA: 2023904 - 3973551)

D 19:54:34 CryptGetHashParam(ImageBuilder, HP_HASHSIZE) - Size: 16 - Length: 4

D 19:54:34 CryptGetHashParam(ImageBuilder, HP_HASHVAL) - Length: 16

I 19:55:07 Synchronising Cache...

I 19:55:08 Closing Track...

I 19:55:16 Finalising Disc...

I 19:56:26 Image MD5: 47f7a8801d0ce2d92e3ac0dd3795e673

I 19:56:26 Exporting Graph Data...

I 19:56:26 Graph Data File: C:\Program Files\ImgBurn\PIONEER_DVD-RW_DVR-111L_8.29_9-25-2007_7-37_PM_MKM-001-00_6x_DVD.ibg

I 19:56:26 Export Successfully Completed!

I 19:56:26 Operation Successfully Completed! - Duration: 00:19:03

I 19:56:26 Average Write Rate: 7,745 KB/s (5.6x) - Maximum Write Rate: 8,690 KB/s (6.3x)

I 19:56:26 Cycling Tray before Verify...

I 19:56:53 Device Ready!

I 19:56:53 Operation Started!

I 19:56:53 Source Device: [1:0:0] PIONEER DVD-RW DVR-111L 8.29 (H:) (ATA)

I 19:56:53 Source Media Type: DVD+R DL (Book Type: DVD-ROM) (Disc ID: MKM-001-00) (Speeds: 2.4x, 4x, 6x, 8x)

I 19:56:53 Image File: -==/\/[bUILD IMAGE]\/\==-

I 19:56:53 Image File Sectors: 3,973,552 (MODE1/2048)

I 19:56:53 Image File Size: 8,137,834,496 bytes

I 19:56:53 Image File Volume Identifier: DVD

I 19:56:53 Image File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!

I 19:56:53 Image File Implementation Identifier: ImgBurn

I 19:56:53 Image File File System(s): ISO9660, UDF (1.02)

I 19:56:54 Verifying Sectors... (LBA: 0 - 3973551)

I 19:56:54 Verifying Layer 0... (LBA: 0 - 2023903)

I 20:06:16 Verifying Layer 1... (LBA: 2023904 - 3973551)

D 20:14:37 CryptGetHashParam(ImageBuilder, HP_HASHSIZE) - Size: 16 - Length: 4

D 20:14:37 CryptGetHashParam(ImageBuilder, HP_HASHVAL) - Length: 16

D 20:15:05 CryptGetHashParam(Device, HP_HASHSIZE) - Size: 16 - Length: 4

D 20:15:05 CryptGetHashParam(Device, HP_HASHVAL) - Length: 16

I 20:15:05 Device MD5: 47f7a8801d0ce2d92e3ac0dd3795e673

I 20:15:05 Image MD5: 47f7a8801d0ce2d92e3ac0dd3795e673

I 20:15:05 Exporting Graph Data...

I 20:15:05 Graph Data File: C:\Program Files\ImgBurn\PIONEER_DVD-RW_DVR-111L_8.29_9-25-2007_7-37_PM_MKM-001-00_6x_DVD.ibg

I 20:15:05 Export Successfully Completed!

I 20:15:05 Operation Successfully Completed! - Duration: 00:18:11

I 20:15:05 Average Verify Rate: 7,284 KB/s (5.3x) - Maximum Verify Rate: 10,450 KB/s (7.5x)

[LIGHTNING UK!]

D 19:35:45 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2144640

.

.

.

D 19:36:16 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 1986768

D 19:36:16 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2086912

D 19:36:16 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2086912

 

Did you change something? It seems to think you did.

[fordman]

Did you change something? It seems to think you did.

 

No, I didn't change a thing. Here's what I did, as I typically do:

 

1. Prepare source files with PGCEdit, use PGCEdit's "Burn DVD/Create ISO" just to see potential layer break positions, set the seamless flag manually in PGCEdit, save the source files (note that I remove the backup directory first), and then exit PGCEdit. I've noted the sector number that PGCEdit calculated at this point, by the way.

 

2. Open ImgBurn and press F6 to enter debug mode, add the root directory for the DVD to the build job. Note that I usually employ a directory structure such as the following

 

DVD_NAME

Burn

VIDEO_TS

AUDIO_TS

 

So I add the Burn directory as the root of the build job.

 

3. I set custom dates and labels in the job

 

4. I then press the calculate icon in Imgburn - it presents me with layer break choices, none of which match that calculated by PGCEdit

 

5. If I haven't already, I add a blank DVD (usually it's already inserted)

 

6. I press the Write icon in Imgburn - it presents me with layer break choices, with at least one matching my choice that PGCEdit calculated

 

7. The burn proceeds and finishes fine!

 

So, as you can see I've done nothing outside of ImgBurn between the calculation and write stage. As I've said, I've encountered this three times in the past months, though by the volume of DVDs I burn, I'd estimate that amounts to less than 5% of the instances. In addition, since the sector calculated by ImgBurn's write mode is correct, the DVD is written correctly with the desired LB. The only time I was thrown off was the one time when ImgBurn stated there were no appropriate layer break positions when I pressed calculate, but as I said when I pressed write, it found potential LB positions, one of which matched what I had chosen/calculated with PGCEdit.

 

What also seems to prove that I'm not changing anything between the "Calculate" and the "Write" is the fact that the sector number at ImgBurn's write stage matches PGCEdit's calculated sector number for the same sector. If I was changing some data between the Calculate and Write stages in Imgburn, you'd expect that the sector number at the Calculate stage would match PGCEdit's, and THEN change when the Write stage started...

 

So, if this is a spurious error with the sector calculations, it is hard to duplicate when it only happens in less than 5% of the instances, and it is of little consequence since it ends up writing correctly. I only mention it in case you wanted to examine possible reasons. You are probably bored since 2.3.2.0 has had little complaints since it was released! :-) Seriously, it looks like you've squashed all or most of the bugs...

 

Any ideas how I can troubleshoot further?

 

Regards,

fordman

Edited September 27, 2007 by fordman

[LIGHTNING UK!]

If there's no disc in the drive it goes by the details on the media tab for sizes of media etc.

 

Those values are changing and they shouldn't do because they're read from the media.

 

If the min/max values are different, so will the LB ones be.

 

So if you calculate when there's a disc in the drive, they'll come out the same as when you hit the write button - but possibly not if you calculate when there isn't.

 

So switch back to 'output' -> 'image file' and look at the Advanced -> Media tab.

 

You may find your 'double layer' profile doesn't match the media you're using.

[fordman]

If there's no disc in the drive it goes by the details on the media tab for sizes of media etc.

 

Those values are changing and they shouldn't do because they're read from the media.

 

If the min/max values are different, so will the LB ones be.

 

So if you calculate when there's a disc in the drive, they'll come out the same as when you hit the write button - but possibly not if you calculate when there isn't.

 

So switch back to 'output' -> 'image file' and look at the Advanced -> Media tab.

 

You may find your 'double layer' profile doesn't match the media you're using.

 

OK, I checked and (without any DVD+DL blank inserted), here's what my profile shows:

 

(* = enabled profile on Media tab)

 

Single Layer:

 

* DVD+R/RW: Maximum Sectors: 2295104

DVD-R/RW: Maximum Sectors: 2298496

DVD-RAM & Custom: Maximum Sectors: 2236704

 

Double Layer:

 

* DVD+R DL: Min Sectors in L0: 0 / Max Sectors in L0: 2086912 / Media Capacity: 4173824

DVD-R DL & Custom: Min Sectors in L0: 2092896 / Max Sectors in L0: 2092896 / Media Capacity: 4171712

 

and the ONLY double layer media I ever use is Verbatim MKM-001-00, which Device mode properties match the DVD+R DL profile on the Media tab.

 

What is interesting is this part of the log:

 

D 19:35:45 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2029184

D 19:35:45 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2144640

.

.

.

I 19:35:51 Using Layer Break LBA: 2023891 -> 2029184 (....................)

 

If you add the MaxL0 and MaxL1 capacities together it equals 4173824, which matches the Media Capacity for DVD+R DL, which would indicate that profile is active even when no blank has been inserted yet. However, it seems curious that the number for MaxL1 sectors is greater than that for MaxL0 sectors. Doesn't DVD+R DL require that L0 be larger than L1? Also, it appears the Calculate function wants to pad L0 out to the maxmum of 2029184 sectors - why? So, whether a blank is inserted or not, why does Imgburn assume that it must pad L0 out to the maximum?

 

OK, though I can't verify for sure if this was one of the instances where I inserted a blank between the Calculate and Write operations, I do know that I was doing that recently in the past few days. So, it seems that the discrepancy is indeed due to not having a blank inserted first, and I can avoid it by having the blank in from the beginning. However, the question remains why ImgBurn is picking MaxL0 sectors that do not match any profile, and for that matter is providing the same number for the MinL0 capacity, which should be 0....OK, so THAT is why Imgburn wants to pad out to the max - because it believe it is also the min! Hmmmm...so where is Imgburn getting this information from if not from the profile?

 

Of course none of this explains why on that one DVD, the Calculate function provided no usable layer break points, when the DVD was not anywhere near capacity, yet did find them when I wrote the image... I often keeps logs of my write jobs, so I can go back and refer to the MD5 value, so I will try to sift through them to find this odd case, though it was quite some time ago.

 

In the meantime, I'll keep a blank inserted (when in Device mode) before I use the Calculate function!

 

Thanks,

fordman

[LIGHTNING UK!]

It is indeed odd... maybe I'm making up random numbers if there's no disc in the drive and output is set to 'Device'.

 

Now I have more info to go on, I'll look into it.

 

Thanks

[LIGHTNING UK!]

Ok, this really makes no sense.

 

The MinL0DataZoneCapacity value is calculated by dividing the total size of the image by 2.

 

It should work out to the same as

 

(MaxCapacity - MaxPadding) / 2

 

There's ONLY 1 way that value can be changed between when it's first calculated and when it's displayed in the debug log - and that's when it's overridden by a forced GUI setting.

 

The forced GUI setting is used twice. Once during initialisation, where it's taken from the profile selected on the media tab. So if you're on DVD+R DL, that would be 0. (It's the Double Layer - Min Sectors value)

The other time is when you're building direct to a disc and it's read from the media currently in the drive.

 

So all I can think is that you're burning 2 DL discs, the first has finished but is still in the drive - ImgBurn reads that LB address from it and as this is fixed in place, it becomes the new minimum L0 size value.

So the 'old' discs minimum LB is being used as the new minimum in the 'Calculate' function and either you're lucking and ImgBurn can still align some cells with the fixed LB position or it can't (hence the failures you mentioned).

You then change the disc to a blank one and hit the 'Write' button. The program has a complete different set of min/max values to work with and everything works as it should do.

 

*Technically*, ImgBurn isn't doing anything wrong as it's basing it's calculations on what you've provided it with - i.e. a burnt disc!

[fordman]

So all I can think is that you're burning 2 DL discs, the first has finished but is still in the drive - ImgBurn reads that LB address from it and as this is fixed in place, it becomes the new minimum L0 size value.

So the 'old' discs minimum LB is being used as the new minimum in the 'Calculate' function and either you're lucking and ImgBurn can still align some cells with the fixed LB position or it can't (hence the failures you mentioned).

You then change the disc to a blank one and hit the 'Write' button. The program has a complete different set of min/max values to work with and everything works as it should do.

 

*Technically*, ImgBurn isn't doing anything wrong as it's basing it's calculations on what you've provided it with - i.e. a burnt disc!

 

OK, I've verified that your theory would indeed behave as you describe. I inserted an already finalized DL DVD, and then added a new set of files in build mode and pressed the Calculate button. Indeed, it showed padding my selected layer break point out to the exact number of sectors that was in L0 of the already finalized DVD.

 

My usual procedure is burn DVDs in my Pioneer drive, double-click the .ibg in the log to open DVDInfoPro and save the graph to hard drive, then move it to my Plextor drive for file-by-file verification (the Plextor had become unreliable for writing). Then while I'm verifying by creating a .SFV file from the DVD to my hard drive (to be matched with the one I've already created from the mounted image), I begin building the job for the next burn in the Pioneer. So, this procedure would normally preclude such an occurrence, but I cannot swear that I removed the finalized DVD from the Pioneer drive in this instance. However, I will go back and look at the log of the prior write job and see if the L0 sectors in that match the initial estimate (2029184) in the log I posted here. If that matches, then that will be irrefutable proof this is what happened. In that one odd instance where there were initially no valid LB points, it's possible I had a very small burned DVD, like a DivX file or something similar, already in the drive.

 

So, if this proves to be the case, I apologize for setting you on a "wild goose chase." However, perhaps we've at least uncovered an opportunity to add some error checking to make it "idiot proof" (for idiots like me, apparently). For instance, you could have ImgBurn ignore the sectors on a burned DVD in the drive and default to the media profile, or return an error at that point - perhaps something like "Please insert a blank DL disc into the drive, or switch to image ouput before calculating potential layer break points." Even though Imgburn isn't technically doing anything wrong as is, such an error check might make it more intuitive...

 

Stay tuned, when I get home again, I'll sift through my logs to verify that my prior write job was still in the drive...

 

Thanks,

fordman

[LIGHTNING UK!]

As it happens, I've already implemented new code for such occasions.

 

If the disc isn't empty, it no longer uses the LB info.

 

Of course that isn't an issue at the write stage (rather than calculate) because I already know the disc is empty or the write button wouldn't be enabled. That's why it appeared to be a calculate issue and not one with write - but it's actually running identical code both times.

[fordman]

As it happens, I've already implemented new code for such occasions.

 

If the disc isn't empty, it no longer uses the LB info.

 

Of course that isn't an issue at the write stage (rather than calculate) because I already know the disc is empty or the write button wouldn't be enabled. That's why it appeared to be a calculate issue and not one with write - but it's actually running identical code both times.

 

Wow, you are way ahead in all the tweaks!

 

OK, I've verified that without a doubt ImgBurn's Calculate WAS looking at the previous write job that was already finalized - I found the log and it's L0 sectors match exactly that in the Calculate section of the log I posted here. However, in finding my log for that previous job, I also discovered why it happened in my normally regimented approach. Read on if you are interested in the details:

 

1. The previous job was a .ISO/.MDS image file combination. I ALWAYS have ImgBurn set to verify immediately after writing. So in this case the DVD was written in my Pioneer DVR-111L drive, and was then in the middle of verifying in the same drive.

 

2. The computer locked up during the verification - I think I unplugged my USB scanner accidentally, and this tends to do that for some reason... CTRL-ALT-DEL didn't work, so I had to power down and boot windows back up.

 

3. After running some chkdsk tests, I moved the burned DVD to my Plextor PX-716A drive, and then opened ImgBurn in Verify mode and verified the DVD in the Plextor drive to the image. This was verified by the fact that my saved log for this prior job only has the verification log in it - I lost the write log when the computer locked up. I closed Imgburn and then followed up with my usual file-by-file verification of the same DVD from the Plextor drive.

 

4. I closed ImgBurn, and opened it later with a blank in the Pioneer drive, as usual, and I pressed the Calculate button. However, ImgBurn was looking at my Plextor drive (Imgburn is set to default to the most recently used device), which still had the prior job in it, and it looked at that DVD instead of the blank in the Pioneer drive. I now recall realizing this when I went to write and found that the button was greyed out, and I then switched it to the Pioneer drive and pressed write.

 

Viola - different sector estimates for the exact reason you theorized! Since Imgburn doesn't identify the drive looked at when estimating the LB sectors in device mode, the posted log alone was insufficient to help me recall this sequence of events, and prior log having only verification information was the key.

 

You guessed the issue without the benefit of that prior log! (EDIT: Smiley added for LUK! at blutach's suggestion!)

 

Please check your PM about something important!

 

Thanks,

 

fordman

Edited September 29, 2007 by fordman

[blutach]

Helluva bird dog job.

 

(Where's that clap hand smiley?)

 

Regards