Gappy Atrac Files With Sonicstage

[oburgoyne]

I've been using SonicStage for quite a while now and have always imported songs by either copying straight from CD or using the Nero method of a CD image and ImageDrive. I later thought it might be easier for me to just import WAV files and convert them using SS instead of using the longer process of creating an image file first.

Anyway, I've noticed that when I import a set of WAV files and convert them to ATRAC3, some tracks that are supposed to blend seamlessly into each other have a very tiny gap between them - it's small but still noticeable, so therefore very annoying. It's like the gap you get with MP3s which is precisely the reason why I was quite happy using ATRAC, a "gapless" codec.

Has anyone else experienced this problem? Does anyone know a way around it?

Thanks.

Incidentally, I've read in the manual for n-code (an ATRAC3 convertor for the program SonicStudio) that truly gapless file conversion is possible as long as the WAV files are converted in that program's batch mode, but SS seems to have a problem doing this.

I've added a capture of the relevant section of the n-code manual below, just so you can see what I mean:

Edited February 23, 2005 by oburgoyne

[bug80]

I've never managed to get gapless conversion with SS either. It's a shame, because ATRAC is gapless by nature.

For true gapless encoding, an encoder must "glue" two files together. This is not possible if two files are encoded completely seperate (as opposed to batch processing). SS simply can't perform batch processing, because it transfers a file to MD while converting the next one.

[dex Otaku]

There is only one relatively simple way to ensure gapless playback:

That is to make a CD image with tracks marked inside a single, contiguous sound file [of all the tracks that run together], and rip it either with SS or simple burner.

WAV files are not guaranteed to be gapless unless you rip them securely with something like EAC that can be adjusted for read offsets. If you're ripping an entire CD at once, offsets aren't absolutely necessary - SS/SB will drop trackmarks on an exact frame [i.e. tracks will be an exact length in frames rather than ending up padded].

This is not a defect of HiMD or ATRAC in any of its incarnations. This is a limitation imposed by the requirement of exact framelengths [based on the original CD audio framerate of 75fps].

[oburgoyne]

WAV files are not guaranteed to be gapless unless you rip them securely with something like EAC that can be adjusted for read offsets.  If you're ripping an entire CD at once, offsets aren't absolutely necessary - SS/SB will drop trackmarks on an exact frame [i.e. tracks will be an exact length in frames rather than ending up padded].

This is not a defect of HiMD or ATRAC in any of its incarnations.  This is a limitation imposed by the requirement of exact framelengths [based on the original CD audio framerate of 75fps].

All of my CDs have been ripped to my hard drive with EAC, so the framelength/FPS issue isn't a problem. I guess that, from what the n-code manual says, that the program that converts the WAV files in SS really would need a special command to make sure that the files remain "gapless".

I've been using the CD image/ImageDrive solution, but it just seems to be a bit of a hassle to go about it this way. I prefer to rip CDs first since (and this may seem a little anal ) some CDs have track marks that begin with a burst of the end of the previous song (QOTSA's Rated R is a very, very good example of this) and I like to "re-adjust" the track marks slightly with WaveLab (taking care to keep exact framelengths) and then creating an image. That way, after ripping them into SS from the CD image, it makes playing them back on my HD1 a slightly more pleasureable listening experience.

Oh, and I've made sure that the WAV files I've tried to convert in the past haven't had any unnecessary headers or "padding" in them that some audio editors sometimes add, so that's not been a problem either.

Oh well, I guess I'll stick with the CD image solution until they implement a decent batch processing mode in SS, which I guess means never. Unless SS 3.0 has some nice surprises in store for us...?

[dex Otaku]

All of my CDs have been ripped to my hard drive with EAC, so the framelength/FPS issue isn't a problem. I guess that, from what the n-code manual says, that the program that converts the WAV files in SS really would need a special command to make sure that the files remain "gapless".

This is only true if you've 'calibrated' EAC's read offset using a CD that is in its offset database. Otherwise there's no knowing that you're reading exactly from the beginning to exactly the end of any given track. This is part of the nature of CD-DA, which lacks a precise positioning system.

[Note that the "easy" way to tell if what you're using will end up padded is to divide its sample length by 75fps; if you get an integer in answer, you're fine. If not, it will end up padded.]

..some CDs have track marks that begin with a burst of the end of the previous song (QOTSA's Rated R is a very, very good example of this) and I like to "re-adjust" the track marks slightly with WaveLab (taking care to keep exact framelengths) and then creating an image.

See - that little burst of the previous track at the beginning of whatever track is usually there because that's the nearest exact frame boundary to the beginning of the actual track of music. If it's so far off that you can move track markers on an exact frame.. well - they were being sloppy when they mastered it. [Yes, I've seen a number of CDs like this, too.]

Under most circumstances, the fact that you're editing it means you're making the track an inexact framelength, hence making it literally impossible for gapless playback to occur on either MD/HiMD or burned CDs made from your edited source.

If you're being really careful to maintain the exact framelength, it should [in theory at least] still work. If you're still getting gaps between tracks that you've done this with, I'm honestly not sure what else to suggest. It certainly sounds like you're doing things within the rules, so to speak.

Of course, for this to work you have to move the beginning of a track -and- the ending of the last track. Every track that has to run into another track [whether at beginning or end] has to be an exact framelength. It sounds like you know this already, but I say that for benefit of anyone else reading this.

Oh, and I've made sure that the WAV files I've tried to convert in the past haven't had any unnecessary headers or "padding" in them that some audio editors sometimes add, so that's not been a problem either.

Most software that uses WAV files will recognise where the actual audio stream begins [i.e. where the header ends] and strip the header anyway, but kudos to you for your knowing to be beware of with this.

Oh well, I guess I'll stick with the CD image solution until they implement a decent batch processing mode in SS, which I guess means never. Unless SS 3.0 has some nice surprises in store for us...?

Yeah. You know, I did try using SS as a music library for a short while, but gave up on it entirely. So much of what I do with my music depends on being able to manipulate things in multiple applications that I found it entirely pointless to use SS for anything more than just uploading and downloading.

Most of the time when I'm making compilations, it's going to end up on at least two formats anyway - HiMD and CD-DA. I do my editing for CD, then rip the results using Simple Burner as well as to an image file with cuesheet from EAC, which I then convert to FLAC for "archival".

FLAC images with cuesheets are how I store all my CD backups now. It may seem cumbersome, but since discovering [rather late in the game] foobar2000 [which can play the FLAC images directly with track tags from the cuesheet] this has become my preferred way to do things.

Cheers.