Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 13 of 13

Hybrid View

  1. #1
    Join Date
    October 2018
    Location
    France
    Posts
    20

    Multitrack record feature

    Hi Team !

    I'm using the Multitrack record feature to record my RPG session. After importing audio to Adobe Suite (Audition, then Premiere Pro), I observed that all wav tracks does not have the same duration. Which is a bit a pain because then you have to synchronize each track to another.

    Could you fix it so every track recorded has the same duration ?

    PS : During those sessions, everyone (track) was connected from start to end. So, not an issue with someone joined after record started.

    Also, for each client recorded the File name contains the nickname which is good. But the recorder does not. Could you fix it also ?

    Best Regards,
    Lix

  2. #2
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    The difference in duration is a result of different end cuts, i.e. I don’t write unnecessary silence at the end of tracks.
    The start points however should be all on the same Timestamp.
    If you have to move the tracks to different time positions to have them in sync, you have found a bug we hadn‘t seen in internal testing.

  3. #3
    Join Date
    July 2019
    Location
    London
    Posts
    1

    Thanks.

    Thanks for information! I have same problem before.

  4. #4
    Join Date
    October 2018
    Location
    France
    Posts
    20
    I confirm. I have to manualy sync the tracks in Premiere Pro.
    It's like if each tracks starts recording in the same CPU thread one after another.

    The miss-synchronization of 0.10 to 0.41 seconds.
    At 0.10, it's almost not observable (just feels strange, but most people don't find why), but at 0.41, it is very disturbing.


    However, I think you should considere writing empty ends so it's more intuitive for content creators to work with.
    And btw, probably more easy to find the bug because like this, all tracks should have the same duration.

  5. #5
    Join Date
    August 2015
    Posts
    55
    As from my work as audio technician I know both sides and just give some information to the team to consider:

    Sure, you don't like to have empty files or just silence at the end or the beginning. Also you might should disable tracks which are not used in one recording session as it would just be a waste of storage.
    BUT: As first there is a job called "cutter" (yeah I know there is also one for synchronizing but this should normally not be used for that low side recording and has other and more psychological resons behind it). If my recorders would just always delete silence on their own I or somebody cutting things would have much more to do. Alright, timestamps could work but not as soon as video recording with different recorders pops in (in normal circumstances).
    I could surely think about an option in my recorders to just make a new file if there is silence. That would just need some RAM and some code working as like an audio-gate does just recoded for producing a new file.
    The problem is: As people working with the audio or also video you want the raw files. How often did I get shitty encoded or cutted stuff and had to go hours to finally get raw material from the customer and do all the shit on my own in minuts what others tried in days. Since most events today just need to be fast and nobody is going to prepare things properly anymore, you can find lots of stuff which has sort of those problems.
    People working live with audio and video just want raw files with everything in it! We are there to know it, we are there to work with it and there is much less to do at the end, since you use gates, compressors and some other stuff anyways.

    Cheers guys

  6. #6
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    Well, to put things into perspective a bit, no audio person needs to hold back here, if you throw a request at us like "I'd like some Mixer view with four insert vst plugin slots and a Neve-style EQ per TS channel", that's understood (and if it ain't there's always the google and the inquire). I'll leave it up to speculation if I could knock such out by tomorrow , but it'd be understood.
    So, while I would claim to know my bit about audio, I definitely don't know all, especially when it comes to the area of broadcasting or video.

    Hence, let's draft the how and why it came to the silence cutting the way it is.

    (Cutting silence on start)
    In the feedback thread of the client beta, there was the request to not put silence at the start and use the timestamp filename convention instead.
    Argument pro: If someone only says sth. after 45mins, there's otherwise a lot of wasted space.
    I had thought about that, but decided against it, because while the former situation can arise, no denying that, cutting silence in the beginning every single person using the feature would have to always manually synchronize every single track. That's cumbersome. I also didn't find it very attractive to add some sort of silence-period threshold that'd switch behaviour. I found the benefit wouldn't justify the cost for anything else than putting all tracks on a common start point - especially given that there's such a thing as a time frame given for implementing "Multitrack 1.0", I'd rather aim for a robust core functionality than enthusiastically adding things on top already.

    (Cutting silence in the middle of things)
    Also, following that, the next logical step would be "what if someone says sth., then doesn't for 45mins, then says sth.". Going down that road would've only made sense for me using some other format capable of putting those clips in a container, OMF, AAF? Support for those kinds of formats was both a bit out of scope for the time we wanted to invest in this feature for now, as well as there's the problem that support for those kind of formats isn't as wide spread amongst audio editors as I would've liked. Technically wav even has that, however that is again rarely supported. Hence "Stem export", leaving silence in.

    (Cutting silence at the end)
    For silence at the end, and we're not talking -80dB, -200dB, we're talking pure, digital zeros silence here, where there's no breath to be accidentally cut due to a gate threshold setting or anything like that, I simply didn't and admittedly still don't see any negative impact on doing that. However I'm happy to learn if there is. You'll just have to talk extra slow

    ---------------------------------------------
    @lightpsycho
    I'm not entirely sure if you disagree with the reasoning above or sth. else specifically, or just wanted to share some insights from someone in the audio engineering biz?

    QA couldn't reproduce that offset that leads to Lix [PLS] having to manually synchronize the tracks.
    I suspect network jitter [correction] could be the hidden cause here instead of some general miscounting of samples in the recorder itself. We'll keep on trying to spot misbehaviour.

  7. #7
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,801
    I know the first part about cutting silence at start was likely my suggestion, unless there where others that also suggested.

    I would still like like an option though if there is any more updates to this area of TS3. Example of why I dislike leading empty on files for users that join later in a session: If a user leaves the channel 5 times and returns every time that is 6 files for that one user, assuming they were there at the start of the recording. But if they do that 45 minutes into a session you end up with about nearly 4 hours (0:45 * 5 = 3:45) of tape if on each join a file is created with silence back to the start time of the recording.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. [Resolved] Doesn't work Start Multitrack Recording
    By PavelKotov in forum Bug Reports [EN/DE]
    Replies: 6
    Last Post: December 17th, 2019, 09:24 AM
  2. SRV record help
    By Col_Crunch in forum General Questions
    Replies: 15
    Last Post: December 21st, 2013, 04:49 AM
  3. Replies: 0
    Last Post: June 19th, 2013, 06:56 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •