|
Poster:
|
BBrofman |
Date:
|
September 30, 2004 12:54:39am |
|
Forum:
|
etree
|
Subject:
|
Re: Are known errors in shows @ the LMA allowed? |
Thanks for your quick reply.
I didn't know that a user who isn't the original uploader could submit file repairs/updates, etc.
Sorry to come off harshly or antagonistic (if I did) ... I guess I just don't know all of the in's and out's of how it works here.
What would we do without the LMA?
Thanks.
|
Poster:
|
 Brad Leblanc |
Date:
|
September 30, 2004 04:26:09am |
|
Forum:
|
etree
|
Subject:
|
Re: Are known errors in shows @ the LMA allowed? |
Regarding Sector Boundary Errors, there is an additional issue that makes fixing them on the Archive.org end extremely difficult -- If a show has a SBE on d1t1, in order to fix it you need to be able to rewrite every track following it in the same directory - thus doubling the space that the show takes up. This process requires a lot of disk space, and a lot of system resources. Many of the download servers are 98% full - the space required isn't there, so fixing it now also requires moving the show to a different server that DOES have enough space.
Basically, it's a lot easier for us if you follow Matt's advice and just fix it and upload another copy of the show. After your copy has been imported, you can fill out an error report letting us know that the old version can be removed (please include a summary of what has been done).
what really bothered me about the file errors that I reported was that the error reports are removed (apparently this is LMA policy)
Argh... This really bothers me. The thing you need to understand is that the only things set in stone are those found in the FAQ section (and even that changes from time to time...) The folks involved with this project are pretty open minded, so if you make a suggestion to improve something it's always considered - especially if that suggestion is followed by volunteering some work to accomplish it.
I closed your report because, like Matt mentions, I didn't think it justified all the work I outlined above. Like I said, that SBE is an inaudible one if you burn the show as-is, which is how the taper intended it and how I was thinking last night when I was reviewing your Error Report. There are hundreds of other error reports still open and untouched where the SBE's are residing in the middle of sets.
However, your comments brought to light the issue of Compilations and Fillers - both good points. As such, I have changed my opinion and would recommend fixing that track moving forward.
Removing user error reports doesn't give the LMA users the opportunity to evaluate what other users have discovered about the shows here
When first introduced, error reports were intended as an "open to-do items" list for the admins - they were not intended as a communication point for users. As such, when an issue was resolved, the report was closed and is removed from the list so admins can see what is left "to-do" with sorting through what has been closed (it is however archived). This has changed, but the functionality of the field has not - I agree that seeing closed error reports linked to items would be nice. This might be worthy of a feature request (see Useful Links section to the left of LMA homepage).
I didn't know that a user who isn't the original uploader could submit file repairs/updates
If the re-upload is just fixing SBE's, knock yourself out! No seeder will complain about that. You're not reprocessing audio and it is nice to have them fixed.
I'll add an FAQ entry about SBE's as soon as I can - it'd be nice to get some of the other 200+ SBE related error reports closed.
-Brad
This post was modified by Brad Leblanc on 2004-09-30 11:26:09
|
Poster:
|
BBrofman |
Date:
|
September 30, 2004 09:25:37am |
|
Forum:
|
etree
|
Subject:
|
Re: Are known errors in shows @ the LMA allowed? |
Brad,
Thanks again for your quick reply.
Now that I know more about how the Archive (and it's tireless admins) work, I'm a lot happier about the situation.
I'll be glad to properly repair the 2 shows that I reported and upload them to the Archive. I'll need some help on the procedure for reporting the uploaded corrections. So when we get to that point, I'll give you a holler.
In fact, I'm now considering helping out with some of the "200+ shows" with SBE's, etc. that need repairs. Can you point me in the right direction where I can look into doing some of these track-related corrections?
Thanks.
Ben Brofman
This post was modified by BBrofman on 2004-09-30 16:25:37
|
Poster:
|
Brad Leblanc |
Date:
|
September 30, 2004 07:18:19pm |
|
Forum:
|
etree
|
Subject:
|
Re: Are known errors in shows @ the LMA allowed? |
Shoot me an email Ben, and I'll send you a list. Thanks for offering!
-Brad
bleblanc_AT_archive_DOT_org
This post was modified by Brad Leblanc on 2004-10-01 02:18:19
|
Poster:
|
Matt Vernon |
Date:
|
September 30, 2004 11:52:29pm |
|
Forum:
|
etree
|
Subject:
|
Re: Are known errors in shows @ the LMA allowed? |
FYI - fixing sbe's CORRECTLY is not as simple as it might first appear, i.e. running the show through shntool using the fix option. Though this would technically make the shntool report show no sbe's, you might still have audio pops or gaps at the track transitions.
The best way is to rejoin each set into a single wav file, use a wav editor that allows resolution down to single samples, go to each track boundary and confirm that the transition is continuous with no gaps. This is important if you have a set that spans audio disks as usually there is some padding even if there is no sbe!
I just mention this because the mechanical application of say shntool to fix sbe's might not produce the pristine audio experience you might be expecting.
There are additional issues which are too detailed to go through here but I thought I would mention at least this much
Matt Vernon
|
Poster:
|
Brad Leblanc |
Date:
|
October 01, 2004 02:38:41am |
|
Forum:
|
etree
|
Subject:
|
Re: SBE's |
Thanks for the post Matt, a response question.
FYI - fixing sbe's CORRECTLY is not as simple as it might first appear, i.e. running the show through shntool using the fix option. Though this would technically make the shntool report show no sbe's, you might still have audio pops or gaps at the track transitions
This is news, so bear with me.
As I understood SBE's, they caused pops when burning shows to CD because the spot chosen for the split point wasn't on a "Sector Boundary". Essentially, the this is a Sector Boundary Error on the split:
0000000000|00000SBS
Where the split is designated by the " | ", the sector boundary by the " B "
However, to be inaudible on a CDR it would have to be cut like this:
000000000000000S|S
So what I thought SHNtool was doing is just plucking that split out and moving it onto the Sector Boundary without changing the music (designated by the 00000's). There isn't a "pop" in the music to remove, the pop you hear is caused by the CD player not liking the split placement - the CD format requires all splits to be on Sector Boundaries to make the split transparent to the listener.
If that's true, why would you need to merge/resplit the whole show when all the tool does is move that splitmark? Does SHNtool leave a "gap"? Seems to me folks wouldn't use it if it did.
Am I missing some info? Please let me know so we can do this correctly.
-Brad
This post was modified by Brad Leblanc on 2004-10-01 09:38:41
|
Poster:
|
Matt Vernon |
Date:
|
October 01, 2004 02:28:06am |
|
Forum:
|
etree
|
Subject:
|
Re: SBE's |
Let me explain by example. Lets start with a master dat or a clone dat of the master that is an exact digital replica of the original master (no added diginoise from the cloning process, etc...). I also assume that this dat has been transfered to a single wav file on a computer without introducing errors, that is, there is a "bit perfect" transfer to the wav files (no diginoise added, no gaps, no analog sampling re-digitization) and the music recorded didn't need multiple dats to cover a single set of the performance so we can ignore dealing with using multiple dats to reconstruct a long uninterrupted set. If this wav file is then tracked without attention to staying on sector boundaries, and the tracked wav files on the computer converted to shn or flac (lossless) and uploaded to say the IA, then these shns or flac tracks could be downloaded by someone and they could use shntool -fix to repair the sbe's without lossing any samples or adding and gaps or silent samples except as padding on the last track. However, if the end of the last track did not fade out before we do the shntool fix then it is possible that the padded zeros will produce an audible pop at the end because the waveform will have a discontinuous jump or a discontinuous first derivative, either of will cause a high frequency burst. This still may be acceptable depending on the MAGNITUDE of the disconintuity in the waveform or its first derivative.
Case 2 - Hidden SBE's. Let's assume now that the originally tracked music with sbes are burned to audio disks and then someone uses these audio disks and EAC to produce digital wav files on their pc they will use to convert to shn or flac. Irrespective of whether your drive used for extraction is EAC offset calibrated, since the audio disks only know the staring point of each track and by the audio standard these are constrained to fall on sector boundaries, the extracted audio files will show no sector boundary errors even though the audio files when played will produce the same audio pops that you hear when you listen to the audio cds. So the effect of the sbe's are preserved even though shntool will say there are no sbe's. In this case one has to go in and append the tracks to gether and zoom in and remove the zero samples at each transition between tracks to reconstruct the original continuous sequence of music that existed from the transfer of our dat (assuming EAC is exact and there were no errors when the audio disks were created) and then retrack on sector boundaries.
Case 3 - If standalone or multiple EAC generations have occurred between the original dat and the audio disks finally used to create the shn set, there can be samples lost or gaps added usually within 10-50 milliseconds of the track transitions. These will "sound" like sbe errors but are actually different and arise from the imperfections of the hardware used to duplicate audio disks. Again, the solution is to use a good editing package to clean up the pops, but in this case you cannot recover the original waveform because it has been irrevocably altered.
Case 4 - Inter-set Mixing
This is perhaps the most common error. A show with sbe's is fixed by putting all the tracks in one directory and running shntool -fix. If the show has more than one set, and if sbe's occur in the early sets, then shntool will borrow some of the samples from the start of say set 2 to complete the sector for the last track of set 1. In this case the best way is to put the tracks for each set in separate directories or restrict the shntool to only fix a single set at a time. This procedure is labeled "fixed-by-set" and is explicitly called out by people to signal that they paid attention to this detail.
Case 5 - Sets longer than one audio disk
Here if you use EAC to extract a long set, you will have to go in and inspect the transtions from the end of one audio disk to another to capture zero samples added from both the last EAC step and the previous tracking history. There is no mechanical way to avoid doing a detailed explicit inspection to insure that the set can be reconstructed and played seemlessly. Since the "disk flips" are an artifact of our present media and media is getting longer, it is best to master the music so it can be seemlessly played without fades etc since in the future we won't be limited by 74, 80 or 90 minute audio disks.
In the specific case that spawned this discussion, it could be that its a simple fix. There is a spectrum of compulsiveness that one can bring to this. The best case is to explicitly confirm by actually listening on headphones that the tracks play continuously across transitions after the wavs are known to be cut on sector boundaries using an audio application on your pc that enables you to reassemble into a single file your cut tracks or knowing that you started with a seemless single file then used CDWAV to cut the tracks on sector boundaries.
|
Poster:
|
Brad Leblanc |
Date:
|
October 02, 2004 03:53:37am |
|
Forum:
|
etree
|
Subject:
|
Re: SBE's |
Very good info Matt. We'll take all of this into consideration before recommending folks make SBE fixes. Ben, can you shoot me an email if you're still with us? (address above)
-Brad
This post was modified by Brad Leblanc on 2004-10-02 10:53:37
|
Poster:
|
BBrofman |
Date:
|
October 02, 2004 04:33:16am |
|
Forum:
|
etree
|
Subject:
|
Re: SBE's |
Correct me if I'm wrong, because I want to present my findings on the best ways to fix the 1st case scenario and the 4th - the only two that I really have any experience with correcting...
In the 1st case you presented, isn't one of the best ways to avoid the zero padding and the audible popping as follows?: Leave all tracks of a single set in a single folder. Place any known SBE-ok file (of the same type: SHN, FLAC, WAV, etc) into the folder of the file(s) to be fixed...the file can be copied from any other known SBE-ok set. Rename the known SBE-ok track anything that will place that file at the end of all of the files in the set (ex: "zzzz.flac"). Use shntool -fix. The "dummy file" ("zzzz.flac") receives the zero padding instead of the final track in the set that you are trying to fix. This avoids the problem of zero padding in the final track of the set that you are fixing...and the "dummy file" is simply deleted. (Right?)
The same method applies to your Case 4 scenario, except different sets are first seperated into different folders, or shntool -fix is manually commanded to only fix each set seperately. (But if sets are not seperated into different folders, then the "dummy file" will have to appear alphabetically after the last track of the first set, and another copy of the "dummy file" has to appear alphabetically after the final track of the second set, etc. etc.)
Does this sound right to you?
|
Poster:
|
Matt Vernon |
Date:
|
October 02, 2004 05:28:23am |
|
Forum:
|
etree
|
Subject:
|
Re: SBE's |
Sorry - but I don't have much time to pursue this further. The bottom line is you need to actually LISTEN to the wav files to determine if there is a problem, but you need to understand that the method you use to listen might not reveal the effect. If you listen carefully and correctly and hear nothing, don't fix it. If you do hear something, then you need to fix it and listen to your fix to confirm it is now ok. Your confirmation listening but be done with the appropriate attention and with the correct method. You cannot substitute the listening steps with the text output from a computer program.
You should take a seed and experiment with it and try some fixes to convince yourself you are doing it correctly.
Matt Vernon
TVNews
OpenLibrary