I was told by someone over at www.sharingthegroove.com (trading community) that this is a no-no.

I'm a total newbie on lossless compression but it is my understanding that if I were to do shn > wav and then back to shn, my new shn files would be identical to the original shn. Am I correct?

Did a search first without getting an answer, so please be kind to me if this has been asked over and over.

/Spinoza

yes, in lossless codecs, it would be identical.
but, why do you want to do a SHN-->Wav-->SHN conversion?

Well, I had a show that I quickly burned to audio CD and then deleted the original shn files. I still had the wav files and when someone wanted a bittorrent window opened and noone seemed to be able to help out, I decided to jump in.

So, I re-encoded the wav files to shn and with help from the original MD5 file I was able to confim that they were identical. Shouldn't I be able to help out? My bittorrent client said I had successfully downloaded the show when I pointed it to the 'new' files.

I assume you are familiar with bittorrent. If not here is an explanation.

This part of your post answers your question adequately: if the existing MD5 sums are correct for the new SHNs, you have successfully re-created the original files.

The simplest reason SHN > WAV > SHN is frowned upon is to keep newbies (or folks who simply haven't taken the time to configure Exact Audio Copy for read/write offsets) from spreading files which are almost correct, but have a tiny bit of the previous or next track attached, due to differences in the way their own drive extracts audio.

Another reason this is viewed as a dangerous practice is that if one is transcoding from a non-seekable SHN (SHNv2) to a seekable SHN (SHNv3) - or vice-versa - the MD5 sums will not match, although the extracted WAV data will be unchanged.

Again, if your re-created files passed the MD5 check from the original, downloaded files, then you had a properly configured system and no harm is done. Just don't encourage everyone to do this, because many folks are not as careful as you were... and it will get you flamed to heck and back by folks who don't really understand the conversion process.

- M.

The reason why it is a nono is probably that can't be sure the shn files are bit identical. Only that the decoded audio is if you use different shorten versions.
Different encoder version might be a little better or something and compresses a little more. then you don't have bit identical files and your version though just as good can't be used to resume from the other version of the show.

Not with SHN files; although there are alternate settings available (if someone really felt a need to lower the quality of the audio) there are only two flavours of lossless SHN: SHNv2 and SHNv3.

What's more, the only difference between the two flavours is that SHNv3 has a seek table appended; SHNv2 is non-seekable.

What this means is that if someone startw with a SHNv2 file, decodes it to WAV, and re-encodes to SHNv2 (and doesn't do anything stupid like deliberately telling the encoder to sacrifice quality!), the output SHNv2 file will always be identical to the original. And if you do the same for SHNv3->WAV->SHNv3, the SHNv3 files - with appended seek tables - will always be identical.

Shorten uses a frozen format; different compiles will not produce different output. Various compiles add new features, but do not affect performance. (The latest codec, Shorten 3.5.1, is able to encode both SHNv2 and SHNv3 by specifying either -v 2 or -v 3 in the command line. All SHN files, regardless of whether they are SHNv2 or SHNv3, are backward-compatible with earlier versions... so even if you have used the latest encoder to create your SHNs you may use the earliest version available to decode them, and still produce identical WAVs.)

At any rate, if the MD5s for the original, downloaded show are still available, they can be used (as Spinoza did) to verify that the SHNs have been accurately re-created.

- M.

Edit: The only exception I can think of to this is the possible bug when generating seek-tables with the RareWares version of Shorten; in that case, SHNv3 files would be bit-identical with those generated by the reference encoder until the beginning of the invalid seek-data. (I do not know for certain whether this bug affects seek-tables appended to SHNv3 files, or if it is only present when generating separate seek-tables (*.skt), but if it's not already been fixed this could be an issue.)

Thanks M

Very enlightening indeed. This is the type of quality response that makes HA a great place.

/Spinoza