Frionil Fang
Now, I'm making a presumption here that sounds, like other assets, should be checking for existing duplicates based on some kind of hashing and not create copies, much like it works for textures.
The encoding used in sound upload is nondeterministic and prevents this: it uses a random value for the Vorbis stream serial number, which results in binary differences as the metadata is different even if the audio data itself may not be.
Steps to reproduce:
  1. Prepare any SL-acceptable .wav file for upload.
  2. Upload the same file to Second Life twice.
  3. Copy and write down the asset UUID for the first file, then the second. Confirm they do not match.
  4. Browse to temp files directory and guesstimate which files are the .ogg files based on size and date. Rename the .tmp to .ogg to test audio playback.
  5. Perform a binary file compare: there will be a couple mismatches, often the same byte patterns, suggesting the metadata is the only thing that has changed.
Curtailed results from Windows FC:
fc /b 3b53c3a9-c301-b9d3-9318-47383d0b2488.ogg 79705d70-6488-60bc-5c6c-03e5882598f0.ogg
Comparing files 3b53c3a9-c301-b9d3-9318-47383d0b2488.ogg and 79705D70-6488-60BC-5C6C-03E5882598F0.OGG
0000000E: E3 97
0000000F: 4F 6D
...
00000DDC: E3 97
00000DDD: 4F 6D
...
00002F38: E3 97
00002F39: 4F 6D
...
The code in question is in llaudio\llvorbisencode.cpp, encode_vorbis_file() function: ogg_stream_init(&os, ll_rand());. Maybe it should be computing a hash of the .wav file to use as a serial instead, if asset duplication is not intentional for sounds.