Markers lost when dithering from 24 to 16 bit

[Robert2413]

I just completed my first transfer with DC7 using 24-bit depth. I was dismayed to find that when I saved a copy of the file as a 16-bit file using highpass dither, all of my track markers disappeared, so I couldn't chop the file into pieces for CD transfer. The only work-around I could think of was to chop the file into 24-bit pieces and then dither each one individually.

I can't believe that this is the way the program is intended to work. What's the secret for preserving the markers when reducing bit depth?

[Craig Maier]

Marker placement is intended to be the last step in a restoration process before burning a CD. That is why the Marker placement routine (Find and Mark Silent Passages) is found under the CD prep menu.

[Robert2413]

Marker placement is intended to be the last step in a restoration process before burning a CD. That is why the Marker placement routine (Find and Mark Silent Passages) is found under the CD prep menu.

But that's not how I work. I drop markers during the editing and restoration process because I am already at the proper location. (Sometimes the location of markers is very critical.) I don't see any reason why the markers need to be lost when the file is saved with the same sample rate but a different bit depth. I would appreciate it if this issue would be addressed in a future update.

I can report some more issues.

1. I usually move an edited file from DC7 to DC6 to chop the files because I haven't figured out if and how DC7 can create CUE files. (I use these with xxxxx to burn CDs.) When I saved the chopped files as 16-bit files with the same name as the 24 bit files, DC6 wrote overwrote the 24-bit files with tiny 44 byte files instead of overwriting the 24-bit files with 16-bit files. (I needed to retain the same file names so that the CUE file would work. I suppose I could go in and edit the CUE file manually, but this is more time wasted.)

2. Then I tried burning a CD from DC7 using the Burn CD menu after I had DC7 chop the files. This appeared to be converting the files to 16-bit automatically, but when the program tried to burn the CD to my Plextor writer, it gave up after 15 seconds, reporting an "unknown error" from the CD burner. And if the 16-bit files were somewhere on my computer, they certainly weren't in the working directory with the 24-bit files.

3. In any event, I *never* want the burner to add 2-second gaps to my CDs. There should be an option to turn this off, like xxxxx has. (A forced 2-second gap sort of makes the whole "quantize for CD audio" feature moot anyway.)

4. Other missing features from the burner software:

--No option to burn more than one CD of the same material.

--No choice of dither type when converting from 24 to 16 bit.

[Dan McDonald]

Robert -

I believe the CD burner is added as a convenience only, and so does not have all the features you might find in a stand-alone cd burning software. It is also burning at redbook standards, which I don't believe allow for the elimination of gaps (but I may be wrong on that).

In regard to your other issue, I would think you'd want to save your 24-bit files for archival purposes and burn the 16-bits to CD, but if you're just burning them to CD, then why is it inconvenient to mark the 16-bit rather than the 24-bit versions? I don't see the difference.

In terms of the 2-second gap and the quantize for CD, it comes in quite handy when you want to burn seemless CDs. You just need to use different software for burning them.

Now that I think about it, though, there must be a way around the 2-second gap problem because I buy commercial classical CDs that I assume are at redbook standards, and they will flow from one section to another. Is that when you see the counter counting backwards into negative numbers? I see that sometimes, where it says -2, -1, 0.

Dan

[sus4chord]

Presumably, marker info is found in the peak file (.pkf) (I'm guessing). I would request that, if possible, that information be preserved between filtering sessions (maybe as a patch update). It's not just the dithering which Robert reported for which it happens. It's anything that results in a destination file (I use the classic system). There have been many times where I've gone through and carefully placed and labeled all my markers (track number and song title), then found an error that required using a filter, and of course without thinking, click "Go" and got my destination file without all my markers.

The only thing that I could think of where keeping markers would be an issue would be if you were stretching or shrinking the file. Otherwise, I don't see why we can't keep the markers between filtering sessions. I'm with Robert on this one.

Or at least make marker preservation an option on the preferences screen.

[Craig Maier]

I do not know how one could hold onto the marker information in classic mode in which a new file name (and peak file) is created for each process.

??

Fast Edit mode is a different situation.

[Dan McDonald]

good point, John. The same kind of thing has happened to me where I find a slight glitch. As long as the file is still exactly the same length, I would think it would be ok, but this wouldn't work if you did anything to alter the length, right?

I've sometimes used a pkf file for an older file, just to see if I could. I think you could have a check box that said 'copy current pkf?' that would simply copy the old one to the new file instead of building a new one, right?

IF so, you might need those warnings to pop up if you did anything that would make it invalid - like stretching or cutting something out, etc.

[Craig Maier]

Anything that you do would make the .pkf invalid in classic edit mode.

Alternative - - -

Fast Edit Mode

[sus4chord]

I do not know how one could hold onto the marker information in classic mode in which a new file name (and peak file) is created for each process.

If I set markers in a file and then close DC7, when I open DC7 back up, the markers are still there. So presumably DC7 knows about them. I'm making the assumption that they are stored in the peak file, but I don't know for sure. But if they are, then the information about them is obviously available. Or even if they are not, the information is obviously available because I can manipulate them after setting them (moving them, removing them, re-labeling them, etc). It seems to me that markers only have a few specific properties that would be fairly easy to capture between filtering sessions (marker #, location of marker - probably an offset to the beginning of the file, and marker label). That information is obviously stored somewhere. It seems to me that it could easily be captured from the current session (maybe to a tempfile or somewhere in RAM - it's not that much data), then when the new peak file is built, the previous markers could be overlaid on the new peak file. If I am able to enter markers manually, then one would think the process could be automated. That doesn't actually sound like too difficult of a programming task.

[sus4chord]

Alternative - - -

Fast Edit Mode

Not to belabor the point, but... (I will)

I find that I prefer classic mode. I do a lot of A-B comparisons after running filters to see if it did what I wanted it to do. Often, I'll scrap a destination file, change the filter parameters and run it again. It's very nice having the source and destination windows to be able to do that. And sometimes, I just reload the original source file and start all over again. So fast edit isn't going to help me there.

So, why not (as I indicated in my previous post) capture the marker information prior to running a filter, run the filter (which creates the destination wav and pkf files), then overlay the marker information. Then when I save the destination file, that information is preserved (if I "save as" a source file with markers in it to a different name, the markers show up in the new file - why would saving the destination file be different).

[Craig Maier]

It sounds like it is essentially creating a hybrid mode somewhere between classic edit mode and fast edit mode.

I fear that it will add a level of confusion to the classic edit mode which could be especially deleterious to the Forensics users who rely on it to maintain an accurate history.

If you provide this new mode, you must be sure that you know what state it is in so that the .pkf does not tell a lie to the user.

What is the problem with using Fast Edit mode for this type of work? I know that Forensics users use the Classic Edit mode so that a complete history exists of the audio enhancement process. This new feature could be problematic for them, especially if they forget about its setting.

Sidebar:

It is worth noting here that Classic Edit mode allows you to place different markers in the source and destination workspaces. This feature is quite useful for Forensics situations in which one needs to identify unique features in the wavefile after a processing step.

[Dan McDonald]

Anything that you do would make the .pkf invalid in classic edit mode.

Alternative - - -

Fast Edit Mode

OK - that makes sense to me. Users like me tend not to think of how exact the markers are. So I think Craig is saying that there is not an exact corrolary when you create a new file. That is, if you put in a marker at 3:14 and you change the file, the 3:14 is not exactly where you were before, which means that the marker information is invalid.

Sounds like fast edit is the way to go with it.

Dan

[sus4chord]

I fear that it will add a level of confusion to the classic edit mode which could be especially deleterious to the Forensics users who rely on it to maintain an accurate history.

I'm sorry, I don't mean to be dense, but I must be missing something.

In Classic Edit mode (I'm not talking about FastEdit at all here), when I run a filter on a file in the source window (which is where I would do that), it's going to create a destination file in the bottom window, with nothing in it but the wav file and the waveform display (which I understand is in the peak file).

Are you saying that if you had markers show up there that were already in the source file, that would cause a problem for forensic users? Just because they were there? Because they want only a blank slate after running the filter?

The markers were placed into a source file in the first place, and so I don't see how them being present in a (non-time stretched) destination file would cause any problems. It also only takes one command (already in DC7) to remove all markers (and if this were an option, then it wouldn't be an issue at all).

Once my (non-time-stretched) altered source is in the destination workspace, then it seems to me that adding, changing, deleting or otherwise altering the markers should be no different than if they were in the source workspace. Everything I can do with markers in the source window I can do in the destination window. The only thing I can't do is to get the markers that were in the source window into the destination window (when, as it is, all the information in the destination window resulted from information originally obtained in the source window), other that to manually add it back in at that point (because I can see where the are in the source window, so it's easier to do it while both are open).

I don't mean to beat a dead horse (yes, I know it's a feature not currently present), but I'm obviously missing something here. Am I that far off in this.

I don't do criminal forensics; I just convert record albums and tapes to CD, so I have markers for every track, because ultimately, the file is going to be chopped into separate tracks (both for CD and for creating MP3s).

But I'm just not seeing how carrying marker over from a source file to the destination file is going to cause problems. Again, as an option, you don't have to see them at all, and even if you do see them, you can very quickly right click and remove all of them.

Anyway, I've had my say, and I hope this will at least be considered as a possible feature enhancement either for the next version or as a patch upgrade within this version. As it is now, it's just extra time to recreate the markers in those instances where I had already created them, but found I had to do something different to the file.

[Dan McDonald]

I think Craig is saying that when you run the filter, it changes the file, for nearly all of the filters, which will throw off the pkf file. For simple things (like record album cuts) and simple changes, it's probably close enough that you wouldn't notice if the marker was tied to a time point, but for more complex applications, it may throw off the markers enough that it doesn't make sense to keep them.

John - If I were you, I'd just try it with a file, put in the markers, run the filter, then copu the old pkf file to the name of the new file, and see if that works for you; if it does, then let us know. You'd have to keep track of exactly where in the old file the markers are to make the comparison. Whenever I've done that, it's thrown off the markers enough that I had to rebuild the pkf file and re-do the markers, but you may find that it works for you. The times I've done it have usually been with live concerts, so off by a second or so is too much off.



Dan

[Craig Maier]

Quoting John:

"Are you saying that if you had markers show up there that were already in the source file, that would cause a problem for forensic users? Just because they were there? Because they want only a blank slate after running the filter?"

--------------------------------------------------------

Yes. The reason is that the destination file is a completely new file with a new .pkf. Often, Forensics users will perform a selective filtering on a section of a source file and that result ends up in the destination file. The examiner then places markers at the beginning and the end of the destination file sector that has the selective filtering performed on it to clearly identify where the modification have been made. Thus, the marker locations in a destination file can be unique to itself, which is one of the advantages of Classic Edit mode.

And what I am not getting or understanding is why one just does not use the Fast Edit mode in which this situation does not exist. We could theoretically change the behaviour of the system, but we just need to have a clear rationale why we are doing it and to be in a position to explain to the Forensics folks the new way of doing things. Remember, in the Forensic world, every step of an audio enhancement is documented and the Markers are part of the process.

I hope that makes sense.

Note - one thing does come out of this thread and that is the identification of a bug when a source file is converted from one sample rate or resolution to another and the Markers are lost. It should not do that and we are looking into it.