I'm wondering if the issue is that when we started the recording there was some discussion before we got ready to play that was recorded. I wonder if JamKazam server is using transient detection in early parts of the tracks to automatically align them without a consistent clock source. That's actually an easy way to align the tracks using Logic Pro X flextime markers.
Maybe if we start recording with a click count-in with not talking, the alignment will be better. Trying that today.
Some of the people in JamKazam have to know why it is as described here in the thread.
Why on earth don't they answer?
It seems completely hopeless and below target.
They should be ashamed - and respond quickly.
Does anyone know whether this issue has been resolved?
(12-14-2020, 12:08 PM)Johannes Wrote: Does anyone know whether this issue has been resolved? >>>
Well, did you try?
I understand mileage may vary.
I have two requests in to the Help Desk for answers to the issues for recording. I have not had a SINGLE successful complete recording EVER on JamKazam. Just did one a few days ago, all of the tracks are reported as successfully uploaded, my computer, internet and JK have all been running since the recording, and tonight the Final Mix is now flagged as MIX FAILED - like most of the rest.
How long has it been since this function worked, and when is it likely to work again? I realize it is not the primary purpose of the program, but it IS a feature, and it is a feature we are now PAYING for. The problem is bad enough, no response is salt in the wound.
Larry
Bassman9952@gmail.com
So the problem ist still there, and I'd really like to know whether there is a straight forward way to determine the exact amount of latency between the files, either through the values in the file commentary field, or with another simple method.
I have sent an enquiry to the help desk.
It seems that the error is also present in the mix.ogg, which is worrying, since it seems even JamKazam doesn't know the correct value. This makes the mix.ogg unusable.
My band has been making recordings of JK sessions for most of the last year and we generally do this by importing individual instrument and vocal tracks into a DAW and using that for synchronisation and mixing. There are several observations we've made over this period.
- The amount of latency between any two participants varies throughout a session, so there is probably no simple algorithm for synchronising tracks exactly. For instance, if some packets are lost from one person's feed, they don't get stored in the recorded tracks and that person's tracks are shorter than those of other participants. With my band, we do the synchronisation in a DAW, by hand (and by eye and by ear).
- In a long session there will be considerable drift between tracks between the beginning and end of the session, so you really have to treat each song separately.
- Each participant's local tracks are always synchronised with each other. So when I import tracks into a DAW, I group each person's tracks together and move them around as a group. In my band, each player has a vocal track and at least one instrumental track, so this observation at least halves the synchronisation problem.
- There is usually a point in a song that can be used for synchronisation eg where everyone plays on a particular downbeat.
- If you don't play the kind of music where you can easily find sync points, the other reliable option is to do a quick synchronisation marker before starting each song. A way we have used is for someone to count 1 ,2 , 3, 4 then all strum, pick, blow, hit or make a short identifiable sound that can be used for synch purposes when the tracks are in a DAW. This only takes a few seconds and makes it very easy to line up tracks by eye/ear.
- If one player suffers significant packet loss during a song, there is nothing for it but to cut their recorded tracks and resync after the break.
Cheers,
Steve
I have different experiences:
- for me the amount of latency seems to stay the same in a recording. We do not experience any lost packets in the local files, everything is intact, and once synced they sta together.
- I have not experienced any drift. We recorded for about 25 minutes without stopping yesterday, no drift measurable.
- We play classical music and it is hard to find exact sync points. Approximate sync points are always available, but I'd really like to get it down to a ms.
Hi Johannes,
That is interesting. Just to make sure I'm not going mad, I checked, as an example, the tracks from my band's session on 19th Feb. The session was just under 2 hours long and, looking at the local tracks in a DAW, they are of different lengths, with about half a second's difference between the shortest and the longest. Maybe there is something in the gear we are using, or the settings, that is causing the occasional lost packet. I don't have any experience of mainstream classical music, though I have (once) tried "pre-classical" music--some duets for bass viols. In that case it was quite easy to find synchronisation points at cadences and at points where both instruments play strings of quavers.
Regards,
Steve
Steve: Yes, the recorded tracks are not the same length, but that is not equivalent to the latency. It just means that the remote recording started later and ended later. I have not been able to translate the difference in length to an offset.
The latest from yesterdays recording session:
I had the following files locally:
Track 1 (stereo) and Track 2 (stereo), RT-Mix, all WAVs
My partner sent me the remote track she recorded.
The two local tracks were exactly the same lengths in samples and totally in sync.
The RT-Mix was 110 samples shorter, but nonetheless in total sync with the two local tracks, I could check this easily by playing them together with the polarity reversed, and it cancelled the local tracks completely.
The RT-Mix was also in sync as far as our playing went, I think this is exactly what we heard in the headphones, there is no reason to assume otherwise.
This now allows a very simple way of syncing by just having the remote participant clap his/her hands.
I can load all these tracks into a DAW, and while the local tracks and the RT-Mix start at exactly the same time, I can now move the remote track slightly forward until the clap in the RT-Mix and the remote track align perfectly by looking at the waveform. (I have not been able to cancel the tracks by reversing the polarity, but I assume that's just because what gets sent over the internet is not close enough to the real track.)
In my case the offset was 258ms, but I am not entirely sure this is the same each time, and it almost certainly isn't the same with other setups and internet speeds.
We will record again tomorrow.
I actually doubt that JamKazam has any way of determining the exact latency itself, which is the reason why the final mixes are of no use whatsoever. They are not in sync.
Anyway, with this method I think I can live, for my use it works well enough.
|
