Search results

I'm following my code, and apparently the problem is the writetag command. For some reason, it's not writing the tags. The only thing I've changed on my end is the code from the previous post. After adding to a library, I run the api writetag command to assign it, but for some reason, the tags...

Anteriormente, usé el comando &cmd=makelibrary para cambiar la biblioteca de una canción desde la API, y se conservaron las etiquetas. Ahora uso &cmd=makelibrary <normalize:-9.0|silence|mixpoint:-14.0|bpm> (sin pasar la lista de etiquetas), pero este comando elimina todas las etiquetas. ¿Hay...

Tracks processed without any events. The acceleration time was doubled on one track. And on the third track, it was doubled again, but it was out of range. The third track needed more acceleration than allowed, so timestrach was disabled. However, I can see in the audio that that track started...

In VoiceTrack Remote, a text search (which highlights tracks) and a time and temperature panel (so you can see the temperature and easily add it to voiceovers) would be useful. It also aligns more closely with the desktop version's interface. :)

Clearly, logging doesn't solve the problem. But the idea is to track tracks whose length varies from the calculated length. And try to find out what's causing the track to end early, for example.

Exactly, the improvement was very significant.

In my case, it improved a lot. The generation time went from almost a full hour to 20 seconds.

An additional point I had missed: I'm using an advanced option to not mix beyond the intro of the next track. Perhaps this is making some songs longer. In any case, the previous example was an issue where the start time was earlier than calculated. Clearly, this has nothing to do with this.

Even record when it encounters a file type, which is a problem for now, and does not know its exact duration. it's easier to keep track

I'll be looking into it, it would be useful if the log also recorded the expected duration of a track, vs. the actual duration at the time of playback.

It takes approximately one full hour to generate a one-hour playlist, with 10 categories of 1,500 songs on average. Only the categories that are used count, right? There are global categories with 30,000 songs, but they aren't being used in the presets.

Exactly, improving the start time would greatly improve this feature. In this case, none of the tracks were a file type, so it's strange. Unless the Time Marker has some effect.

Since the new Constraint rules, the time it takes to generate a playlist has increased exponentially. Some optimization would be great.

Intro tracks need to be addressed at some point. But that's not the case in this example, since playback was fast-forwarded rather than delayed. In other cases, it seems to be more accurate, which makes me think there are some cases that haven't yet been addressed when calculating the start...

No, I didn't make a manual adjustment. I even disabled all events for tracking. I see the effort to improve this, but I still think there's more to it. :) The start time is critical for TimeStreach.

Finally the track started before the hour

I'm testing with TimeStreach. I've been following your work track by track. I noticed something strange with file types (the time adjustment changed quite a bit), so I'll keep a close eye on this now. The strangest thing was with the last track's time. I disabled the adjustment, and now the new...

The intro column is very essential in remote voicetracking. With this, the announcer knows how many seconds they have to speak.

Is it possible to see what percentage applies when it's valid? To see how it holds up track to track.

It would be interesting to have the sigue editor as a tab in the workspaces, so you can make changes without opening a new window.